ceph基本架構及數據分佈原理

Ceph做爲雲廠商不可或缺的存儲系統之一，有着優秀的性能、可靠性和可擴展性，是一種統一的、分佈式的存儲系統。可是，你們對ceph的技術原理有了解多少呢？本文主要從ceph概述、ceph的系統結構、數據分配策略三方面對ceph做了詳細的介紹。下來就跟隨做者一塊兒去看看ceph是如何工做的吧。

PS：豐富的一線技術、多元化的表現形式，盡在「360雲計算」，點關注哦！

1

ceph簡述

什麼是ceph

Ceph是一種爲提升性能、可靠性和可擴展性而設計的統一的、分佈式的存儲系統。「統一的」：意味着Ceph一套存儲系統能夠同時提供對象存儲、塊存儲和文件系統存儲三種功能，以便在知足不一樣應用需求的前提下簡化部署和運維。「分佈式」：在Ceph系統中則意味着真正的無中心結構和沒有理論上限的系統規模可擴展性。（在使用方面，各公司會有本身的考慮，作目前最大的ceph集羣，影響ceph圈，引領ceph技術發展？求穩定，控制必定的規模等 ）

ceph的技術特徵是什麼

高可靠性。首先是針對存儲在系統中的數據而言，經過多副本、糾刪碼方式儘量保證數據不會丟失。其次，也包括數據寫入過程當中的可靠性，在用戶將數據寫入Ceph存儲系統的過程當中，經過強一致性寫入，避免由於意外狀況的出現形成數據丟失。高度自動化。具體包括了數據的自動failure detection和自動failure recovery。整體而言，這些自動化特性一方面保證了系統的高度可靠，一方面也保障了在系統規模擴大以後，其運維難度仍能保持在一個相對較低的水平。高可擴展性。這裏的「可擴展」概念比較廣義，既包括了系統規模和存儲容量的可擴展，也包括了隨着系統節點數增長的聚合數據訪問帶寬的線性擴展，還包括了基於功能豐富強大的底層API提供多種功能、支持多種應用的功能性可擴展。ceph的技術這麼優秀，那麼有誰在用？
主要以雲廠商爲主（基本在用OpenStack的，後端存儲都在用ceph）

2

ceph系統的層次結構

自下向上，能夠將Ceph系統分爲四個層次：

1. 基礎存儲系統RADOS（Reliable, Autonomic, Distributed Object Store，便可靠的、自動化的、分佈式的對象存儲）。
2. 基礎庫LIBRADOS層。
3. 高層應用接口層：包括了三個部分：RADOS GW（RADOS Gateway）、 RBD（Reliable Block Device）和Ceph FS（Ceph File System）。
4. 應用層。

Ceph的底層是RADOS的組件：一種是爲數衆多的、負責完成數據存儲和維護功能的OSD（ Object Storage Device）。另外一種則是若干個負責完成系統狀態檢測和維護的Monitor。OSD和monitor之間相互傳輸節點狀態信息，共同得出系統的整體工做狀態，並造成一個全局系統狀態記錄數據結構，即cluster map（monmap osdmap pgmap）。這個數據結構與RADOS提供的特定算法相配合，便實現了Ceph「無需查表，算算就好」的核心機制以及若干優秀特性。

1. OSD（Object Storage Device），能夠被抽象爲兩個組成部分，即系統部分和守護進程（OSD deamon）部分。即一塊磁盤（一些CPU、一些內存），有一個daemon進程對它操做，進行數據存儲和維護，是磁盤的「經紀人」，每一個osd進程服務會監聽一個端口，與其它OSD的daemon、monitor、client通訊。
2. mon：monitor檢測和維護集羣狀態。每一個client訪問OSD都須要先訪問monitor獲取集羣map，從而知道須要和哪些osd節點通訊。

3

數據分佈策略crush

Ceph經過crush規則來控制數據的分佈策略。

crush規則具體解決了什麼問題

1. 控制把對象存入集羣中，並隨機均勻的分佈在全部存儲設備中。
2. 老設備故障，新設備加入時支持數據的自動均衡遷移，並儘量最小化數據遷移。
3. 如何合理分佈多副本數據到不一樣的設備，保證數據較高的可靠性。

兩次映射完成數據的分佈

Object -> PG -> OSD。對象名HASH -> pgid -> (osd1,osd2,osd3)。

1）File ——以rbd塊存儲爲例，此處的file即爲我建立了一個rbd塊，假設我建立了128M的塊，在建立塊時候能夠設定切分紅多大的object存在存儲設備上，默認是4M，以下圖：

2）Ojbect ——在Ceph中，一切皆對象，不管是視頻，文本，照片等一切格式的數據，Ceph統一將其看做是對象，不以它們的格式、大小來區分他們，只以對象名來區分，每一個不一樣的對象都有不同的對象名。從rados層直接put一個對象到集羣中：（原對象多大存入集羣就多大）

從rbd應用接口層存數據到集羣中：（對塊作了切分，打散存入集羣）

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數量的設置牽扯到數據分佈的均勻性問題。

• File -> object：從rados層直接存儲，不對對象作任何處理，只以對象名爲分區將對象存入集羣，若是對象名重複則覆蓋；從應用層，假設從rbd接口應用層存數據，能夠在應用層設定統一切分對象大小，對象名爲 block_name_prefix + ID ，存入後端存儲設備。

• Object -> PG映射：要將不一樣的object映射到PG中去，這裏採用了HASH，hash(對象名)獲得了一串十六進制隨機數，而且對於一個一樣的對象名，計算出來的結果永遠都是同樣的；用隨機數除以PG的總數，求餘，餘數必定會落在0到pg總數減1之間；求餘的好處就是對象數量規模越大，每一個PG分佈的對象數量就越平均，每一個對象自有名字開始，他們要保存到的PG就已經能夠計算肯定了。計算公式：池ID + hash(對象名) / pg_num -> pgid （注：故若是pg_num變化，會影響大量數據從新分佈，假設pg_num從16調整爲32，那麼該池將有約一半數據映射到新增的pg上）。

• PG -> OSD映射：算法的輸出（即算法要達到什麼效果）：CRUSH但願隨機挑OSD出來，要知足權重越大的OSD被挑中的機率越大，爲了達到隨機的目的，它在挑以前讓每一個OSD都拿着本身的權重乘以一個隨機數，再取乘積最大的那個，那麼這樣宏觀來看，一樣是乘以一個隨機數，在樣本容量足夠大以後，這個隨機數對挑中的結果再也不有影響，起決定性影響的是OSD的權重，OSD的權重（容量）越大，宏觀來看被挑中的機率越大。若是咱們想保存三個副本，那麼只須要挑選3個osd，把每一個PG都映射到三個不一樣的OSD上便可。

咱們有哪些輸入

互不相同的PG_ID、互不相同的OSD_ID、OSD的權重（根據osd對應的磁盤容量大小設置）。這裏我直接使用CRUSH裏面採起的Straw算法，翻譯過來就是抽籤算法，Crush算法的過程(有人將該過程形象的描述爲把這些OSD搓一搓，選擇一個最長的籤)：

1. CRUSH_HASH( PG_ID, OSD_ID, r ) ===> draw （搓一搓，獲得一個隨機數，r可認爲是常量）。
2. ( draw &0xffff ) osd_weight ===> osd_straw （隨機數osd權重）。 
3. pick up high_osd_straw 。（挑選乘積最大的osd）
4. 屢次抽籤。（ r+1 繼續下次抽籤，若是挑選的osd重複，則r繼續+1繼續抽籤，直到選夠副本個數個osd ）

關鍵的隨機數， CRUSH但願獲得這樣一個隨機數有什麼要求？該隨機數和PG_ID 有關、與OSD_ID有關，當相同的輸入時，計算得出的輸出值必定是相同的，而且有必定隨機性。（輸出是定值，保證了在集羣池中的PG不變，沒有擴縮容增減osd，沒有調整osd權重的時候，集羣的數據分佈永遠是不變的）

pg到osd的映射過程

1. 給出一個PG_ID，做爲CRUSH_HASH的輸入。
2. CRUSH_HASH(PG_ID, OSD_ID, r) 得出一個隨機數。
3. 對於全部的OSD用他們的權重乘以每一個OSD_ID對應的隨機數，獲得乘積。
4. 選出乘積最大的OSD，這個PG就會保存到這個OSD上。
5. 咱們把r+1，再求一遍隨機數，重複上述過程，選出乘積最大的OSD，若是和以前的OSD編號不同，那麼就選中它；若是和以前的OSD編號同樣的話，那麼再把r+2，再選一次，直到選出咱們須要的三個不同編號的OSD爲止。

Pg到osd的映射過程若是就這樣完成了，怎麼解決故障閾的問題？怎麼人爲定義我想把數據分佈在哪一個機櫃？定義一個樹形結構，該樹形結構中osd以外的節點咱們稱爲bucket；每一個OSD有weight，每一個主機也能夠有一個weight，這個weight由主機內的全部OSD的weight累加而得；每一個rack的weight由全部主機的weight累加而得；root的weight其實就是rack的權重之和；一樣bucket也有ID；仿照CRUSH選OSD的方法來選擇bucket，而且還能夠定義從樹形結構的根節點每次從下層節點選擇多少個bucket。

4

集羣維護

理解了crush算法的原理，其實ceph的集羣維護就是維護集羣的crush規則。（ 即PG_ID/BUCKET_ID/OSD_ID/權重控制PG的映射關係）

1. 新增/刪除OSD（擴縮容） 首先根據配置信息與monitor通訊，monitor將其加入cluster map，並設置爲up或out狀態，權重生效；刪除osd過程相反。
2. 自動化的故障恢復（Failure recovery） 收到monitor發過來的cluster map以後，這個新OSD計算出本身所承載的PG以及和本身承載同一個PG的其餘OSD。而後與這些OSD取得聯繫。若是這個PG目前處於降級狀態（即承載該PG的OSD個數少於正常值），則其餘OSD將把這個PG內的全部對象和元數據賦值給新OSD。數據複製完成後，新OSD被置爲up且in狀態，cluster map更新。