ceph對象存儲

1. ceph這款雲存儲技術怎麼樣

Ceph是一套高性能，易擴展的，無單點的分布式文件存儲系統，基於Sage A. Weil的論文開發，主要提供以下三個存儲服務：
對象存儲(Object Storage)，既可以通過使用Ceph的庫，利用C, C++, Java, Python, PHP代碼，也可以通過Restful網關以對象的形式訪問或存儲數據，兼容亞馬遜的S3和OpenStack的Swift。
塊存儲(Block Storage)，作為塊設備像硬碟一樣直接掛載。
文件系統(File System) ，如同網路文件系統一樣掛載，兼容POSIX介面。

Ceph的結構，對象存儲由LIBRADOS和RADOSGW提供，塊存儲由RBD提供，文件系統由CEPH FS提供，而RADOSGW, RBD, CEPH FS均需要調用LIBRADOS的介面，而最終都是以對象的形式存儲於RADOS里。

Ceph集群的節點有三種角色：
Monitor，監控集群的健康狀況，向客戶端發送最新的CRUSH map(含有當前網路的拓撲結構)
OSD，維護節點上的對象，響應客戶端請求，與其他OSD節點同步
MDS，提供文件的Metadata，如果不使用CephFS可以不安裝
​

2. 【ceph】對象存儲 - bucket命名規范

用於存儲 日誌文件的 存儲桶的名稱必須符合非美國標准區域的命名要求。Amazon S3 將存儲桶名稱定義為符合以下規則的一個或多個標簽（用句點分隔開）：

警告
由於 S3 允許您的存儲桶用作可公開訪問的 URL，因此您選擇的存儲桶名稱必須具有全局唯一性。如果其他一些賬戶已使用您選擇的名稱創建存儲桶，則必須使用其他名稱。有關更多信息，請參閱 Amazon Simple Storage Service 開發人員指南 中的存儲桶局限和限制。

參考
https://docs.aws.amazon.com/zh_cn/awscloudtrail/latest/userguide/cloudtrail-s3-bucket-naming-requirements.html

3. Ceph RGW：數據的存儲及定址

RGW是一個對象處理網關。數據實際存儲在ceph集群中。利用librados的介面，與ceph集群通信。RGW主要存儲三類數據：元數據(metadata)、索引數據(bucket index)、數據(data)。這三類數據一般存儲在不同的pool中，元數據也分多種元數據，存在不同的ceph pool中。

1、 Metadata
元數據信息包括：user，bucket，以及bucket.instance。其中：
user: 主要是對象存儲的用戶信息
bucket：主要維護bucket name與bucket instance id之間的映射信息
bucket.instance：維護了bucket instance信息

查看user的元數據如下：
radosgw-admin metadata list user:

radosgw-admin metadata get user:testid:

radosgw-admin metadata list bucket:

radosgw-admin metadata get bucket:first:

radosgw-admin metadata list bucket.instance:

radosgw-admin metadata get bucket.instance:first:{bucket_id}

2、Bucket Index
bucket index主要維護的是一個bucket中object的索引信息。一個bucket對應一個或多個rados object(開啟bucket shards下)。維護的是一個key-val的map結構，map存放在object的omap(rocksdb)中，key對應的rgw object，val是關於rgw object的一些元數據信息，檢索bucket的存放的object時，需要這些信息。omap也包含一個Header，其存放的是bucket account info，如此bucket中Object的個數，總的size等。
3、Data
rgw object內容，存放在一個或多個rados object中。rados object分為header和tail部分，header最多可以容納512KB的數據，如果一個rgw object的大小小於512KB，那麼只有header。否則剩餘的數據會按照集群rados object的大小條帶化分割成多個rados object。

在Pool： {zone}.rgw.meta利用namespace隔離多個存儲空間：

對於Pool: {zone}.rgw.log也包含多個namespace:

當檢索對象存儲中的一個object時，會包含三個要素：user，bucket,object。user主要是RGW用於獲取user id驗證ACL；bucket及obejct用於確定object在pool中的位置。

User

user數據存儲在 {zone}.rgw.meta:users.uid 中，如下：

包含兩部分： ups3: user本身信息; ups3.buckets: 用戶所屬的bucket。

ups3： 用戶的基本信息，及ACL/Bucekt Quota/User Quota等；對應struct RGWUserInfo， 定義於rgw_common.h。
ups3.buckets：用戶所屬的Buckets，key-value結構，存放於omap結構中；對應struct cls_user_bucket_entry，定義於rgw_common.h，數據操作如下：

通過{uid}.buckets查到用戶具有哪些buckets，並且這些bucket以下基本數據。

Bucket

Bucket信息存在在 {zone}.rgw.meta:root 中，如下：

first： 記錄了bucket與bucket_instance_id的對應關系，其對應於數據結構：struct RGWBucketEntryPoint
.bucket.meta.first:1c60b268-0a5d-4718-ad02-e4b5bce824bf.44166.4： bucket instance；定址方式：.bucket.meta.{tenant}:{bucket.name}:{bucket_id}；對應結構體：struct RGWBucketInfo。
其中Bucket ACL及IAM Policy存放在bucket instance object的attr中。如下：

獲取Bucket ACL及IAM Policy數據如下：

Object

Bucket Index： Bucket中包含的Object信息，都存放在一個或多個Object的 omap 中。此omap為一個key-value結構，key為object的名稱，value對應 struct rgw_bucket_dir_entry : cls_rgw_types.h 。
Bucket Index Object：

如下：

在此bucket下，有一個object: ntp.conf:

檢索value:

omap header記錄了以下統計信息：

對象存儲object的數據存放在pool: {zone}.rgw.buckets.data 中。object的構成及定址分為以下兩類：

一個RGW Object可以由一個或多個rados object構成。其中第一個 object 是此RGW 的 head 對象，主要包含一些元數據信息，如 manifest, ACLs, content type, ETag, and user-defined metadata 。這些metadata存放在此head 對象的xattr中。其中 manifest 描述了此rgw object在分布情況。同時，此head對象，最多可額外容納 4MB 數據，如果RGW Object大小下於 4MB ，那麼此 RGW Object就不會分片，只有此 head 對象。
如下檢索：

目前bucket下有一個 ntp.conf ， <4MB 。檢索其 manifest :

如上：
max_head_size： 表示head對象最大size；
head_size： 表示當前head 對象size；
prefix： 用於在rados中分片object的定址。

RGW OBject ACL:

上傳一個 >4MB 的 RGW Object，檢索其 manifest 信息：

Manifest信息：

根據 manifest 檢索對象：

對於一個大的RGW Object，會被切割成多個獨立的RGW Object上傳，稱為multipart。multipar的優勢是斷點續傳。s3介面默認切割大小為15MB。

在此，上傳一個60MB大小的Object。

分成了四個部分上傳，查看rados對象：

包含了三類對象， head，multipart，shadow 。

multipart 下的 manifest :

所有的object的檢索是根據上述manifest信息構建object index:

在上以上的信息中，此RGW Object大小為48128000位元組，分為4段，三段15MB，最後一段為920KB。同時每段存儲在rados集群中的條帶化大小為4MB。因此15MB大小的分段，也分為4個rados object，一個multipart首部，及3個shadow分片。920KB大小的分段只有一個multipart首部。

.rgw.root :

包含的都是zone,zonegroup,realm等信息

4. 可以把ceph作為對象存儲，用於生產環境嗎

Swift在小文件對象（如圖像）存儲上，性能很好。Ceph目前坑還是比較多，不是很穩定，如果沒有研發能力，只是做對象存儲，不建議在生產環境中用。國內生產環境最大的部署是京東，主要也是為了做塊存儲。

5. c ep h是一種什麼形式的對象存儲系統

ceph是一種形式的對象存儲系統
一、意思不同
.h中一般放的是同名.c文件中定義的變數、數組、函數的聲明，需要讓.c外部使用的聲明。
.c文件一般放的是變數、數組、函數的具體定義。
二、用法不同
.c文件，以c為擴展名，一般存儲具體功能的實現。
.h文件，稱為頭文件，一般存儲類型的定義，函數的聲明等。通常，頭文件被.c文件包含，使用#include語句。但值得注意的是，這只是一種約定，而非強制。

6. ceph（第一步） 基礎架構

ceph 是什麼？
ceph 是一種開源存儲軟體。底層實現了對象存儲，並以此為基礎對外提供對象存儲介面、塊存儲介面、文件級存儲介面。

ceph 結構包含兩個部分：

ceph 版本：Nautilus

官網的一張架構圖：

對於這張圖，一開始沒有看懂它想表達什麼，後來明白了。如下圖：

相關名詞解釋：

ceph 組件分為兩部分：

此部分介紹構成 ceph 集群的基礎組件。
其中包含 OSD、Manager、MDS、Monitor。

此部分介紹 ceph 對外提供各種功能的組件。
其中包含：Block Device、Object Storage、Filesystem。

前面兩個部分主要介紹了 ceph 的一些組件及對外提供的功能。
這部分主要介紹 ceph 的存儲邏輯。

首先，在對象存儲中，一切都是扁平化的，並且存儲的最小單元為對象（obj）。存儲 obj 如下圖：

ceph 在對象存儲的基礎上提供了更加高級的思想。

當對象數量達到了百萬級以上，原生的對象存儲在索引對象時消耗的性能非常大。ceph 因此引入了 placement group （pg）的概念。一個 pg 就是一組對象的集合。如下圖：

obj 和 pg 之間的映射由 ceph client 計算得出。

討論 pg 時，不得不提的另外一個名詞：pgp。
pgp 決定了 pg 和 osd 之間的映射關系。一般將 pgp_num 設置成和 pg_num 一樣大小。

這里還有一個名詞需要提一下，在 ceph 中會經常見到 crush 演算法。簡單來說，crush 演算法就是指 ceph 中數據如何存儲、讀取的過程。

由於 ceph 集群面對許多的獨立項目，因此 ceph 還引入了 ceph pool 的概念用於劃分不同的項目。
ceph pool 是對 ceph 對象的邏輯劃分，並不是物理劃分。

pg 和 ceph pool 的區別：

像大多數集群軟體一樣，ceph 也提供了緩存的概念。稱之為 Cache Tier（緩存層，在具體使用時有時會稱之為緩存池）。
緩存池對用戶來說是透明的，因此不會改變用戶的原有使用邏輯。以下緩存池的介紹，均為底層邏輯。
在沒有緩存池時，ceph client 直接指向存儲池。
在添加緩存池後，ceph client 指向緩存池，緩存池再指向存儲池。

官方原話：
When pg_num is increased for any pool, every PG of this pool splits into half, but they all remain mapped to their parent OSD.
Until this time, Ceph does not start rebalancing. Now, when you increase the pgp_num value for the same pool, PGs start to migrate from the parent to some other OSD, and cluster rebalancing starts. This is how PGP plays an important role.
By Karan Singh
個人翻譯：
當一個池增加 pg 數量時，這個池中的所有 pg 都會變化。但是原 pg 的實際物理存儲位置不會改變。
當一個池增加 pgp 的數量時，pg 的實際物理存儲位置會發生改變。

首先，截至目前，沒有具體查到資料證明以下觀點。（基於一致性hash的猜想）

圖中出現了一個新詞： vosd ，這個是指虛擬 osd。它的數量等於 pgp 的數量，而 pgp 一般又等於 pg。

pgp 的數量就是 vosd 的數量。

引入 pg 可以實現 pool 概念，以及優化碎片管理（這一點十分不確定）。

引入 pgp（vosd），是為了在增加 osd 時可以讓數據更加均衡的分布。

如猜想圖：
當我們增加池的 pg 數量時，不會改變 vosd，因此原 pg 與 vosd 之間的映射未變，原 pg 的實際物理位置也不會發生變化。只是會影響同一個池中 obj 的分布。
當我們增加池的 pgp 數量時，相當於改變了 vosd，通過 hash 計算出的部分 pg 與 vosd 之間的映射就要發生改變，從而導致 pg 的實際物理位置發生改變。

與一致性hash不同的地方：
一般情況下，一致性hash只有一層虛擬化層，並且虛擬化層是根據物理硬體而變化的。但是ceph卻是一種反著來的意思。

當 ceph 增加一個 osd 時，pg 的物理位置也會發生改變。
在該猜想下：
當增加 osd 時，並不會增加 vosd 的數量，原部分 vosd 會映射到新的 osd 上，因此產生一種部分 pg 的實際物理位置發生變化的情況。

創建池時，會分配固定的 pg，以及設置與 pg 一樣大小的 pgp。
注意，一般 pg 數量都設置為 2 的次方。

嚴格意義上，我們無論為池分配多少個 pg 都沒有問題。但有時候 pg num 配置小了會報錯，配置大了也會報錯。這不是因為這么配置不對，是因為有其它的參數在限制我們隨意配置 pg num。

比如：
osd 有兩個配置，當每個 osd 的 pg num 過少（默認30）時會告警，當每個 osd 的 pg num 過多（默認300）也會告警。

所以，想要入門使用 ceph，還是需要了解許多基礎知識才可以。否則，各種意外。

https://docs.ceph.com/docs/master/architecture/

https://ceph.com/pgcalc/

7. ceph原理 Ceph簡單介紹

1、Ceph是一個可靠地、自動重均衡、自動恢復的分布式存儲系統，根據場景劃分可以將Ceph分為三大塊，分別是對象存儲、塊設備存儲和文件系統服務。在虛擬化領域里，比較常用到的是Ceph的塊設備存儲，比如在OpenStack項目里，Ceph的塊設備存儲可以對接OpenStack的cinder後端存儲、Glance的鏡像存儲和虛擬機的數據存儲，比較直觀的是Ceph集群可以提供一個raw格式的塊存儲來作為虛擬機實例的硬碟。

2、Ceph相比其它存儲的優勢點在於它不單單是存儲，同時還充分利用了存儲節點上的計算能力，在存儲每一個數據時，都會通過計算得出該數據存儲的位置，盡量將數據分布均衡，同時由於Ceph的良好設計，採用了CRUSH演算法、HASH環等方法，使得它不存在傳統的單點故障的問題，且隨著規模的擴大性能並不會受到影響。

8. 【ceph】對象存儲的目錄/文件夾概念

對象存儲（OSS）中文件夾的概念僅是一個邏輯概念，在通過API/SDK的方式設置文件夾的時候可以指定object對應的key值包括前面的目錄即可實現該功能。例如，定義object的key為abc/1.jpg就會在該bucket下創建一個abc的文件夾，而在文件夾下即會有一個1.jpg的文件。

對象存儲（OSS）中的文件夾其實是一個大小為0KB的空文件。因此，用戶創建一個key值為1/的object就會定義文件夾1；並且如果用戶創建文件abc/1.jpg，系統是不會創建abc/這個文件的，因此在刪除abc/1.jpg後將不會再存在abc這個文件夾。

由於對象存儲（OSS）採用的是分布式存儲的方式，object並不是根據文件夾進行物理存儲的。也就是說並不是一個文件夾下的所有的文件都會存儲在一起的。在後端存儲的過程中不同的文件夾的文件僅僅是key值的前綴不一樣。因此這種架構下就會導致無法很方便的統計某個文件夾下的匯總信息，如文件夾大小、文件夾PV數等。而想要遍歷某個文件夾下的所有的文件也需要首先通過ListObject介面獲取文件夾下的所有文件的key值（這里需要通過prefix指定文件夾），然後再進行操作。

在邏輯上「中國.mp4」將存放到目錄「videos」中

https://help.aliyun.com/knowledge_detail/39527.html
https://www.jianshu.com/p/4212d37c0e0f

9. ceph 對象存儲多站點同步user id 配置方案

最近在配置多站點的時候，想了好久， 有一個糾結的地方是：

由於在異地有兩套或兩套以上的集群，在配置多站點同步前，需要在主zone上創建一個 網關系統用戶 用於同步，數據的讀取都是依賴這個用戶的許可權。可是時間久了（或者說換了個管理員）， 我怎麼找到當時配置多站點的時候用的是哪個網關用戶呢？也就是用的這個同步的用戶的用戶id是多少呢，看官網文檔的意思是，固定一個用戶id 用做多站點同步，固定一個用戶id就要求，這個固定的id 沒有之前沒有被佔用，

突然想到一個辦法是， 設置zone 的access key 的時候就等同於 system user id,這樣每次查看zone的信息的時候就可以看到access key也就是可以看到用於同步的 system user id，

下面命令get zone info

radosgw-admin zone get

並且用戶信息，zone信息是會在多個zone間同步的， 也就是你在異地的另一個集群也查看到指定的用於同步的網關用戶信息。

當你要更換同步密鑰的時候，更改該用戶的密鑰，然後在相繼所有zone的key就可以了，當然也可以換用其他id的系統以後， 然後把該用戶刪掉就可以了。

此問題解決了如何在異地不同集群上找到用於同步的網關系統用戶，不依賴於第三方的系統。

鏈接： 配置ceph多站點官方文檔

10. Ceph 架構與原理

Ceph 是一個開源項目，它提供軟體定義的、統一的存儲解決方案 。Ceph 是一個具有高性能、高度可伸縮性、可大規模擴展並且無單點故障的分布式存儲系統 。
Ceph 是軟體定義存儲解決方案
Ceph 是統一存儲解決方案
Ceph 是雲存儲解決方案

高可用性

高擴展性

特性豐富

Ceph獨一無二地統一的系統提供了對象存儲、塊存儲和文件存儲功能。Ceph存儲集群由幾個不同的軟體守護進程組成（比較重要的兩個是MON和OSD），每個守護進程負責Ceph的一個獨特功能並將值添加到相應的組件中。

RADOS是CEPH存儲系統的核心,也稱為Ceph 存儲集群。Ceph的數據訪問方法(如RBD,CephFS,RADOSGW，librados)的所有操作都是在RADOS層之上構建的。當Ceph 集群接收到來自客戶端的請求時,CRUSH演算法首先計算出存儲位置,最後將這些對象存儲在OSD中,當配置的復制數大於1時,RADOS負責的形式將數據分發到集群內的所有節點,最後將這些對象存儲在OSD中。當配置的復制數大於1時,RADOS負責數據的可靠性,它復制對象，創建副本並將它們存儲在不同的故障區域中。
RADOS包含兩個核心組件: OSD和MON

OSD 是Ceph 存儲集群中最重要的一個基礎組件，他負責將實際的數據以對象的形式存儲在每一個集群節點的物理磁碟中。對於任何讀寫操作，客戶端首先向MON請求集群MAP，然後客戶端舊可以直接和OSD進行I/O操作。
一個Ceph 集群包含多個OSD。一個典型的Ceph集群方案會為集群節點上的每個物理磁碟創建一個ODS守護進程,這個是推薦的做法。OSD上的每個對象都有一個主副本和幾個輔副本,輔副本分散在其他OSD。一個OSD對於一些對象是主副本，同時對於其他對象可能是輔副本，存放輔副本的OSD主副本OSD控制,如果主副本OSD異常(或者對應的磁碟故障),輔副本OSD可以成為主副本OSD。
OSD是有一個已經存在的Linux文件系統的物理磁碟驅動器和OSD服務組成。Ceph 推薦OSD使用的文件系統是XFS。OSD的所有寫都是先存到日誌,再到存儲.

MON 負責監控整個集群的健康狀況。它以守護進程的形式存在,一個MON為每一個組件維護一個獨立的MAP,如OSD，MON,PG,CRUSH 和MDS map。這些map 統稱為集群的MAP。MON 不為客戶端存儲和提供數據,它為客戶端以及集群內其他節點提供更新集群MAP的服務。客戶端和集群內其他節點定期與MON確認自己持有的是否是集群最新的MAP.一個Ceph集群通常包含多個MON節點,但是同一時間只有一個MON。

librados是一個本地的C語言庫，通過它應用程序可以直接和RADOS通信，提高性能

Ceph 塊存儲，簡稱 RBD，是基於 librados 之上的塊存儲服務介面。RBD 的驅動程序已經被集成到 Linux 內核（2.6.39 或更高版本）中，也已經被 QEMU/KVM Hypervisor 支持，它們都能夠無縫地訪問 Ceph 塊設備。Linux 內核 RBD（KRBD）通過 librados 映射 Ceph 塊設備，然後 RADOS 將 Ceph 塊設備的數據對象以分布式的方式存儲在集群節點中

RGW，Ceph對象網關，也稱做RADOS網關，它是一個代理，可以將HTTP請求轉換為RADOS，也可以把RADOS轉換為HTTP請求，從而提供restful介面，兼容S3和Swift。Ceph對象網關使用Ceph對象網關守護進程(RGW)與librgw、librados交互。Ceph對象網關支持三類介面：S3、Swift、管理API（通過restful介面管理Ceph集群）。RGW有自己的用戶管理體系

Ceph 元數據伺服器服務進程，簡稱 MDS。只有在啟用了 Ceph 文件存儲（CephFS）的集群中才需要啟用 MDS，它負責跟蹤文件層次結構，存儲和管理 CephFS 的元數據。MDS 的元數據也是以 Obejct 的形式存儲在 OSD 上。除此之外，MDS 提供了一個帶智能緩存層的共享型連續文件系統，可以大大減少 OSD 讀寫操作頻率。

CephFS在RADOS層之上提供了一個兼容POSIX的文件系統。它使用MDS作為守護進程，負責管理其元數據並將它和其他數據分開。CephFS使用cephfuse模塊（FUSE）擴展其在用戶空間文件系統方面的支持（就是將CephFS掛載到客戶端機器上）。它還允許直接與應用程序交互，使用libcephfs庫直接訪問RADOS集群。

Ceph管理器軟體，可以收集整個集群的所有狀態。有儀錶板插件

一個對象通常包含綁定在一起的數據和元數據，並且用一個全局唯一的標識符標識。這個唯一的標識符確保在整個存儲集群中沒有其他對象使用相同的對象ID，保證對象唯一性。基於文件的存儲中，文件大小是有限制的，與此不同的是，對象的大小是可以隨著大小可變的元數據而變得很大。對象不使用一個目錄層次結構或樹結構來存儲，相反，它存儲在一個包含數十億對象且沒有任何復雜性的線性地址空間中。對象可以存儲在本地，也可以存放在地理上分開的線性地址空間中，也就是說，在一個連續的存儲空間中。任何應用程序都可以基於對象ID通過調用restful API從對象中獲取數據。這個URL可以以同樣的方式工作在網際網路上，一個對象ID作為一個唯一的指針指向對象。這些對象都以復制的方式存儲在OSD中，因為能提供高可用性。

對於Ceph集群的一次讀寫操作，客戶端首先聯系MON獲取一個集群map副本，然後使用對象和池名/ID將數據轉換為對象。接著將對象和PG數一起經過散列來生成其在Ceph池中最終存放的那一個PG。然後前面計算好的PG經過CRUSH查找來確定存儲或獲取數據所需的主OSD的位置。得到准確的OSD ID之後，客戶端直接聯系這個OSD來存取數據。所有這些計算操作都由客戶端來執行，因此它不會影響Ceph集群的性能。一旦數據被寫入主OSD，主OSD所在節點將執行CRUSH查找輔助PG和OSD的位置來實現數據復制，進而實現高可用。
  簡單地說，首先基於池ID將對象名和集群PG數應用散列函數得到一個PG ID，然後，針對這個PG ID執行CRUSH查找得到主OSD和輔助OSD，最後寫入數據。

PG是一組對象地邏輯集合，通過復制它到不同的OSD上來提供存儲系統的可靠性。根據Ceph池的復制級別，每個PG的數據會被復制並分發到Ceph集群的多個OSD上。可以將PG看成一個邏輯容器，這個容器包含多個對象，同時這個邏輯容器被映射到多個OSD。
  計算正確的PG數對一個Ceph存儲集群來說是至關重要的一步。PG數計算公式如下

Ceph池是一個用來存儲對象的邏輯分區，每個池都包含一定數量的PG，進而實現把一定數量的對象映射到集群內部不同OSD上的目的。每一個池都是交叉分布在集群所有節點上的，這樣就能提供足夠的彈性。池可以通過創建需要的副本數來保障數據的高可用性。
  Ceph的池還支持快照功能，我們可以使用ceph osd pool mksnap命令來給特定的池製作快照。此外，Ceph池還允許我們為對象設置所有者和訪問許可權。

數據管理始於客戶端向Ceph池中寫數據。一旦客戶端准備寫數據到Ceph池中，數據首先寫入基於池副本數的主OSD中。主OSD再復制相同的數據到每個輔助OSD中，並等待它們確認寫入完成。只要輔助OSD完成數據寫入，就會發送一個應答信號給主OSD。最後主OSD再返回一個應答信號給客戶端，以確認完成整個寫入操作。