Ⅰ 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/
Ⅱ 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等信息
Ⅲ 雲計算分布式存儲是用ceph還是hadoop
雲計算的開發需要多種語言共同參與，HADOOP在雲計算產品中只是一個底層框架，適合做雲盤、分布式計算等底層業務。很少有一種雲產品只用一種開發語言解決所有問題的，襪緩語言只是工具，關鍵是要學會在不同的應用場景下，如何正確選擇合適的工具。雲產品的框架有很多，比如OpenStack是用Python寫的，Hadoop是用Java寫的。
Ceph架構簡介及其特點
Ceph簡介
Ceph是一個統一的分布式存儲系統，設計初衷是提供較好的性能、可靠性和可擴展性。
Ceph項目最早起源於Sage就讀博士期間的工作（最早的成果於2004年發表），並隨後貢獻給開源社區。在經過了數年的發展之後，目前已得到眾多雲計算廠商的支持並被廣泛應用。RedHat及OpenStack都可與Ceph整合以支持虛擬機鏡像的後端存儲。
Ceph特點
高性能
a.摒棄了傳統的集中式存儲元數據定址的方案，採用CRUSH演算法，數據分布均衡，並行度高。
b.考慮茄好祥了容災域的隔離，能夠實現各類負載的副本放置規則，例如跨機房、機架感知等。
c.能夠支持上千個存儲節點的規模，支持TB到PB級的數據。
高可用性
a.副本數可以靈活控制顫搏。
b.支持故障域分隔，數據強一致性。
c.多種故障場景自動進行修復自愈。
d.沒有單點故障，自動管理。
高可擴展性
a.去中心化。
b.擴展靈活。
c.隨著節點增加而線性增長。
特性豐富
a.支持三種存儲介面：塊存儲、文件存儲、對象存儲。
b.支持自定義介面，支持多種語言驅動。
Hadoop簡介及其特點
Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。用戶可以在不了解分布式底層細節的情況下，開發分布式程序。充分利用集群的威力進行高速運算和存儲。Hadoop實現了一個分布式文件系統（HadoopDistributedFileSystem），簡稱HDFS。
HDFS有高容錯性的特點，並且設計用來部署在低廉的（low-cost）硬體上；而且它提供高吞吐量（highthroughput）來訪問應用程序的數據，適合那些有著超大數據集（largedataset）的應用程序。HDFS放寬了（relax）POSIX的要求，可以以流的形式訪問（streamingaccess）文件系統中的數據。Hadoop的框架最核心的設計就是：HDFS和MapRece。HDFS為海量的數據提供了存儲，而MapRece則為海量的數據提供了計算。
雲計算的開發語言多樣
hadoop和雲計算是兩回事，HADOOP開發首選JAVA，次選C/C++或者Python雲計算就復雜了，不同的應用又不同額選擇。很少有一種雲產品只用一種開發語言解決所有問題的語言只是工具，關鍵是要學會在不同的應用場景下，如何正確選擇合適的工具。雲產品的框架有很多，比如OpenStack是用Python寫的，Hadoop是用Java寫的。
HADOOP在雲計算產品中只是一個底層框架，適合做雲盤、分布式計算等底層業務。中間層和上層用什麼語言開發取決產品的特性和技術人員的技術特點。
Ⅳ Ceph之Cephfs存儲
CephFS 是一個支持POSFIX 介面的文件系統,它使用Ceph 存儲集群來存儲數據。文件系統對於客戶端來說可以方便的掛載至本地使用。CephFS 構建在RADOS之上,繼承RADOS的容錯性和擴展性,支持榮譽副本和數據高可靠性。
Ceph 文件系統要求 Ceph 存儲集群內至少有一個 Ceph 元數據伺服器
1、為元數據存斗咐儲池設置較空察純高的副本水平，因為此存儲池丟失任何數據都會導致整個文件系統失效。
2、為元數據存沒燃儲池分配低延時存儲器（像 SSD ），因為它會直接影響到客戶端的操作延時。
默認設置為文件系統創建兩個存儲池
Ceph監視器為: 10.65.3.76
Ⅳ 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再返回一個應答信號給客戶端，以確認完成整個寫入操作。
Ⅵ Ceph之塊存儲
塊是一個位元組序列（例如，一個 512 位元組的數據塊）。基於塊的存儲介面是最常見的存儲數據方法，它們基於旋轉介質，像硬碟、 CD 、軟盤、甚至傳統的 9 磁軌磁帶。無處不在的塊設備介面使虛擬塊設備成為與 Ceph 這樣的海量存儲系統交互的理想之選。
Ceph 塊設備是精簡配置的、大小可調且將數據條帶化存儲到集群內的多個 OSD 。 Ceph 塊設備利用 RADOS 的多種能力，如快照、復制和一致性。睜塵余 Ceph 的 RADOS 塊設備（ RBD ）使用內核模塊或 librbd 庫與 OSD 交互。
Ceph 塊設備靠無限伸縮性提供了高性能，如向兄棚內核模塊、或向 abbr:KVM (kernel virtual machines) （如 Qemu 、 OpenStack 和 CloudStack 等雲計算系統通過 libvirt 和 Qemu 可與 Ceph 塊設備集成）。你可以用同一個集群同時運行 Ceph RADOS 網關、 Ceph FS 文件系統、和 Ceph 塊設備。
默認 image 的特性包括：
作為 rbd 一般只需要 layering ，需要把其他的特性全部禁止掉。
克隆獨悉滾立存在，不依賴於快照，就需要對克隆和快照做一個合並
參考:
Blog: https://www.cnblogs.com/hukey/p/13283351.html