史上最全的Ceph介紹、原理、架構

史上最全的Ceph介紹、原理、架構

1. Ceph架構簡介及使用場景介紹

1.1 Ceph簡介

Ceph是一個統一的分布式存儲系統，設計初衷是提供較好的性能、可靠性和可擴充性。

Ceph項目最早起源于Sage就讀博士期間的工作（最早的成果于2004年發表），并随後貢獻給開源社群。在經過了數年的發展之後，目前已得到衆多雲計算廠商的支援并被廣泛應用。RedHat及OpenStack都可與Ceph整合以支援虛拟機鏡像的後端存儲。

1.2 Ceph特點

• 高性能

  a. 摒棄了傳統的集中式存儲中繼資料尋址的方案，采用CRUSH算法，資料分布均衡，并行度高。

  b.考慮了容災域的隔離，能夠實作各類負載的副本放置規則，例如跨機房、機架感覺等。

  c. 能夠支援上千個存儲節點的規模，支援TB到PB級的資料。

• 高可用性

  a. 副本數可以靈活控制。

  b. 支援故障域分隔，資料強一緻性。

  c. 多種故障場景自動進行修複自愈。

  d. 沒有單點故障，自動管理。

• 高可擴充性

  a. 去中心化。

  b. 擴充靈活。

  c. 随着節點增加而線性增長。

• 特性豐富

  a. 支援三種存儲接口：塊存儲、檔案存儲、對象存儲。

  b. 支援自定義接口，支援多種語言驅動。

1.3 Ceph架構

支援三種接口：

• Object：有原生的API，而且也相容Swift和S3的API。
• Block：支援精簡配置、快照、克隆。
• File：Posix接口，支援快照。

  

  rados

1.4 Ceph核心元件及概念介紹

• Monitor

  一個Ceph叢集需要多個Monitor組成的小叢集，它們通過Paxos同步資料，用來儲存OSD的中繼資料。

• OSD

  OSD全稱Object Storage Device，也就是負責響應用戶端請求傳回具體資料的程序。一個Ceph叢集一般都有很多個OSD。

• MDS

  MDS全稱Ceph Metadata Server，是CephFS服務依賴的中繼資料服務。

• Object

  Ceph最底層的存儲單元是Object對象，每個Object包含中繼資料和原始資料。

• PG

  PG全稱Placement Grouops，是一個邏輯的概念，一個PG包含多個OSD。引入PG這一層其實是為了更好的配置設定資料和定位資料。

• RADOS

  RADOS全稱Reliable Autonomic Distributed Object Store，是Ceph叢集的精華，使用者實作資料配置設定、Failover等叢集操作。

• Libradio

  Librados是Rados提供庫，因為RADOS是協定很難直接通路，是以上層的RBD、RGW和CephFS都是通過librados通路的，目前提供PHP、Ruby、Java、Python、C和C++支援。

• CRUSH

  CRUSH是Ceph使用的資料分布算法，類似一緻性哈希，讓資料配置設定到預期的地方。

• RBD

  RBD全稱RADOS block device，是Ceph對外提供的塊裝置服務。

• RGW

  RGW全稱RADOS gateway，是Ceph對外提供的對象存儲服務，接口與S3和Swift相容。

• CephFS

  CephFS全稱Ceph File System，是Ceph對外提供的檔案系統服務。

1.5 三種存儲類型-塊存儲

rbd

典型裝置： 磁盤陣列，硬碟

主要是将裸磁盤空間映射給主機使用的。

優點：

• 通過Raid與LVM等手段，對資料提供了保護。
• 多塊廉價的硬碟組合起來，提高容量。
• 多塊磁盤組合出來的邏輯盤，提升讀寫效率。

缺點：

• 采用SAN架構組網時，光纖交換機，造價成本高。
• 主機之間無法共享資料。

使用場景：

• docker容器、虛拟機磁盤存儲配置設定。
• 日志存儲。
• 檔案存儲。
• …

1.6 三種存儲類型-檔案存儲

fs

典型裝置： FTP、NFS伺服器

為了克服塊存儲檔案無法共享的問題，是以有了檔案存儲。

在伺服器上架設FTP與NFS服務，就是檔案存儲。

優點：

• 造價低，随便一台機器就可以了。
• 友善檔案共享。

缺點：

• 讀寫速率低。
• 傳輸速率慢。

使用場景：

• 日志存儲。
• 有目錄結構的檔案存儲。
• …

1.7 三種存儲類型-對象存儲

rgw

典型裝置： 内置大容量硬碟的分布式伺服器(swift, s3)

多台伺服器内置大容量硬碟，安裝上對象存儲管理軟體，對外提供讀寫通路功能。

優點：

• 具備塊存儲的讀寫高速。
• 具備檔案存儲的共享等特性。

使用場景： (适合更新變動較少的資料)

• 圖檔存儲。
• 視訊存儲。
• …

2. Ceph IO流程及資料分布

rados_io_1

2.1 正常IO流程圖

ceph_io_2

步驟：

1. client 建立cluster handler。

2. client 讀取配置檔案。

3. client 連接配接上monitor，擷取叢集map資訊。

4. client 讀寫io 根據crshmap 算法請求對應的主osd資料節點。

5. 主osd資料節點同時寫入另外兩個副本節點資料。

6. 等待主節點以及另外兩個副本節點寫完資料狀态。

7. 主節點及副本節點寫入狀态都成功後，傳回給client，io寫入完成。

2.2 新主IO流程圖

說明：

如果新加入的OSD1取代了原有的 OSD4成為 Primary OSD, 由于 OSD1 上未建立 PG , 不存在資料，那麼 PG 上的 I/O 無法進行，怎樣工作的呢？

ceph_io_3

步驟：

1. client連接配接monitor擷取叢集map資訊。

2. 同時新主osd1由于沒有pg資料會主動上報monitor告知讓osd2臨時接替為主。

3. 臨時主osd2會把資料全量同步給新主osd1。

4. client IO讀寫直接連接配接臨時主osd2進行讀寫。

5. osd2收到讀寫io，同時寫入另外兩副本節點。

6. 等待osd2以及另外兩副本寫入成功。

7. osd2三份資料都寫入成功傳回給client, 此時client io讀寫完畢。

8. 如果osd1資料同步完畢，臨時主osd2會交出主角色。

9. osd1成為主節點，osd2變成副本。

2.3 Ceph IO算法流程

ceph_io_4

1. File使用者需要讀寫的檔案。File->Object映射：

a. ino (File的中繼資料，File的唯一id)。

b. ono(File切分産生的某個object的序号，預設以4M切分一個塊大小)。

c. oid(object id: ino + ono)。

2. Object是RADOS需要的對象。Ceph指定一個靜态hash函數計算oid的值，将oid映射成一個近似均勻分布的僞随機值，然後和mask按位相與，得到pgid。Object->PG映射：

a. hash(oid) & mask-> pgid 。

b. mask = PG總數m(m為2的整數幂)-1 。

3. PG(Placement Group),用途是對object的存儲進行組織和位置映射, (類似于redis cluster裡面的slot的概念) 一個PG裡面會有很多object。采用CRUSH算法，将pgid代入其中，然後得到一組OSD。PG->OSD映射：

a. CRUSH(pgid)->(osd1,osd2,osd3) 。

2.4 Ceph IO僞代碼流程

2.5 Ceph RBD IO流程

ceph_rbd_io

步驟：

1. 用戶端建立一個pool，需要為這個pool指定pg的數量。

2. 建立pool/image rbd裝置進行挂載。

3. 使用者寫入的資料進行切塊，每個塊的大小預設為4M，并且每個塊都有一個名字，名字就是object+序号。

4. 将每個object通過pg進行副本位置的配置設定。

5. pg根據cursh算法會尋找3個osd，把這個object分别儲存在這三個osd上。

6. osd上實際是把底層的disk進行了格式化操作，一般部署工具會将它格式化為xfs檔案系統。

7. object的存儲就變成了存儲一個文rbd0.object1.file。

2.6 Ceph RBD IO架構圖

ceph_rbd_io1

用戶端寫資料osd過程：

1. 采用的是librbd的形式，使用librbd建立一個塊裝置，向這個塊裝置中寫入資料。

2. 在用戶端本地同過調用librados接口，然後經過pool，rbd，object、pg進行層層映射,在PG這一層中，可以知道資料儲存在哪3個OSD上，這3個OSD分為主從的關系。

3. 用戶端與primay OSD建立SOCKET 通信，将要寫入的資料傳給primary OSD，由primary OSD再将資料發送給其他replica OSD資料節點。

2.7 Ceph Pool和PG分布情況

ceph_pool_pg

說明：

• pool是ceph存儲資料時的邏輯分區，它起到namespace的作用。
• 每個pool包含一定數量(可配置)的PG。
• PG裡的對象被映射到不同的Object上。
• pool是分布到整個叢集的。
• pool可以做故障隔離域，根據不同的使用者場景不一進行隔離。

2.8 Ceph 資料擴容PG分布

場景資料遷移流程：

• 現狀3個OSD, 4個PG
• 擴容到4個OSD, 4個PG

現狀：

ceph_recory_1

擴容後：

ceph_io_recry2

說明

每個OSD上分布很多PG, 并且每個PG會自動散落在不同的OSD上。如果擴容那麼相應的PG會進行遷移到新的OSD上，保證PG數量的均衡。

3. Ceph心跳機制

3.1 心跳介紹

心跳是用于節點間檢測對方是否故障的，以便及時發現故障節點進入相應的故障處理流程。

問題：

• 故障檢測時間和心跳封包帶來的負載之間做權衡。
• 心跳頻率太高則過多的心跳封包會影響系統性能。
• 心跳頻率過低則會延長發現故障節點的時間，進而影響系統的可用性。

故障檢測政策應該能夠做到：

• 及時：節點發生異常如當機或網絡中斷時，叢集可以在可接受的時間範圍内感覺。
• 适當的壓力：包括對節點的壓力，和對網絡的壓力。
• 容忍網絡抖動：網絡偶爾延遲。
• 擴散機制：節點存活狀态改變導緻的元資訊變化需要通過某種機制擴散到整個叢集。

3.2 Ceph 心跳檢測

ceph_heartbeat_1

OSD節點會監聽public、cluster、front和back四個端口

• public端口：監聽來自Monitor和Client的連接配接。
• cluster端口：監聽來自OSD Peer的連接配接。
• front端口：供用戶端連接配接叢集使用的網卡, 這裡臨時給叢集内部之間進行心跳。
• back端口：供客叢集内部使用的網卡。叢集内部之間進行心跳。
• hbclient：發送ping心跳的messenger。

3.3 Ceph OSD之間互相心跳檢測

ceph_heartbeat_osd

步驟：

• 同一個PG内OSD互相心跳，他們互相發送PING/PONG資訊。
• 每隔6s檢測一次(實際會在這個基礎上加一個随機時間來避免峰值)。
• 20s沒有檢測到心跳回複，加入failure隊列。

3.4 Ceph OSD與Mon心跳檢測

ceph_heartbeat_mon

OSD報告給Monitor：

• OSD有事件發生時（比如故障、PG變更）。
• 自身啟動5秒内。
• OSD周期性的上報給Monito
  • OSD檢查failure_queue中的夥伴OSD失敗資訊。
  • 向Monitor發送失效報告，并将失敗資訊加入failure_pending隊列，然後将其從failure_queue移除。
  • 收到來自failure_queue或者failure_pending中的OSD的心跳時，将其從兩個隊列中移除，并告知Monitor取消之前的失效報告。
  • 當發生與Monitor網絡重連時，會将failure_pending中的錯誤報告加回到failure_queue中，并再次發送給Monitor。
• Monitor統計下線OSD
  • Monitor收集來自OSD的夥伴失效報告。
  • 當錯誤報告指向的OSD失效超過一定門檻值，且有足夠多的OSD報告其失效時，将該OSD下線。

3.5 Ceph心跳檢測總結

Ceph通過夥伴OSD彙報失效節點和Monitor統計來自OSD的心跳兩種方式判定OSD節點失效。

• 及時：夥伴OSD可以在秒級發現節點失效并彙報Monitor，并在幾分鐘内由Monitor将失效OSD下線。

• 适當的壓力：由于有夥伴OSD彙報機制，Monitor與OSD之間的心跳統計更像是一種保險措施，是以OSD向Monitor發送心跳的間隔可以長達600秒，Monitor的檢測門檻值也可以長達900秒。Ceph實際上是将故障檢測過程中中心節點的壓力分散到所有的OSD上，以此提高中心節點Monitor的可靠性，進而提高整個叢集的可擴充性。

• 容忍網絡抖動：Monitor收到OSD對其夥伴OSD的彙報後，并沒有馬上将目标OSD下線，而是周期性的等待幾個條件：
  • 目标OSD的失效時間大于通過固定量osd_heartbeat_grace和曆史網絡條件動态确定的門檻值。
  • 來自不同主機的彙報達到mon_osd_min_down_reporters。
  • 滿足前兩個條件前失效彙報沒有被源OSD取消。

• 擴散：作為中心節點的Monitor并沒有在更新OSDMap後嘗試廣播通知所有的OSD和Client，而是惰性的等待OSD和Client來擷取。以此來減少Monitor壓力并簡化互動邏輯。

4. Ceph通信架構

4.1 Ceph通信架構種類介紹

網絡通信架構三種不同的實作方式：

• Simple線程模式

  特點：每一個網絡連結，都會建立兩個線程，一個用于接收，一個用于發送。

  缺點：大量的連結會産生大量的線程，會消耗CPU資源，影響性能。

• Async事件的I/O多路複用模式

  特點：這種是目前網絡通信中廣泛采用的方式。k版預設已經使用Asnyc了。

• XIO方式使用了開源的網絡通信庫accelio來實作

  特點：這種方式需要依賴第三方的庫accelio穩定性，目前處于試驗階段。

4.2 Ceph通信架構設計模式

設計模式(Subscribe/Publish)：

訂閱釋出模式又名觀察者模式，它意圖是“定義對象間的一種一對多的依賴關系，

當一個對象的狀态發生改變時，所有依賴于它的對象都得到通知并被自動更新”。

4.3 Ceph通信架構流程圖

ceph_message

步驟：

• Accepter監聽peer的請求, 調用 SimpleMessenger::add_accept_pipe() 建立新的 Pipe 到 SimpleMessenger::pipes 來處理該請求。

• Pipe用于消息的讀取和發送。該類主要有兩個元件，Pipe::Reader，Pipe::Writer用來處理消息讀取和發送。

• Messenger作為消息的釋出者, 各個 Dispatcher 子類作為消息的訂閱者, Messenger 收到消息之後，  通過 Pipe 讀取消息，然後轉給 Dispatcher 處理。

• Dispatcher是訂閱者的基類，具體的訂閱後端繼承該類,初始化的時候通過 Messenger::add_dispatcher_tail/head 注冊到 Messenger::dispatchers. 收到消息後，通知該類處理。

• DispatchQueue該類用來緩存收到的消息, 然後喚醒 DispatchQueue::dispatch_thread 線程找到後端的 Dispatch 處理消息。

ceph_message_2

4.4 Ceph通信架構類圖

ceph_message_3

4.5 Ceph通信資料格式

通信協定格式需要雙方約定資料格式。

消息的内容主要分為三部分：

• header              //消息頭，類型消息的信封
• user data          //需要發送的實際資料
  • payload     //操作儲存中繼資料
  • middle      //預留字段
  • data          //讀寫資料
• footer             //消息的結束标記

5. Ceph CRUSH算法

5.1 資料分布算法挑戰

• 資料分布和負載均衡：

  a. 資料分布均衡，使資料能均勻的分布到各個節點上。

  b. 負載均衡，使資料通路讀寫操作的負載在各個節點和磁盤的負載均衡。

• 靈活應對叢集伸縮

  a. 系統可以友善的增加或者删除節點裝置，并且對節點失效進行處理。

  b. 增加或者删除節點裝置後，能自動實作資料的均衡，并且盡可能少的遷移資料。

• 支援大規模叢集

  a. 要求資料分布算法維護的中繼資料相對較小，并且計算量不能太大。随着叢集規模的增 加，資料分布算法開銷相對比較小。

5.2 Ceph CRUSH算法說明

• CRUSH算法的全稱為：Controlled Scalable Decentralized Placement of Replicated Data，可控的、可擴充的、分布式的副本資料放置算法。

• pg到OSD的映射的過程算法叫做CRUSH 算法。(一個Object需要儲存三個副本，也就是需要儲存在三個osd上)。

• CRUSH算法是一個僞随機的過程，他可以從所有的OSD中，随機性選擇一個OSD集合，但是同一個PG每次随機選擇的結果是不變的，也就是映射的OSD集合是固定的。

5.3 Ceph CRUSH算法原理

CRUSH算法因子：

• 階層化的Cluster Map

  反映了存儲系統層級的實體拓撲結構。定義了OSD叢集具有層級關系的 靜态拓撲結構。OSD層級使得 CRUSH算法在選擇OSD時實作了機架感覺能力，也就是通過規則定義， 使得副本可以分布在不同的機 架、不同的機房中、提供資料的安全性 。

• Placement Rules

  決定了一個PG的對象副本如何選擇的規則，通過這些可以自己設定規則，使用者可以自定義設定副本在叢集中的分布。

5.3.1 層級化的Cluster Map

ceph_crush

CRUSH Map是一個樹形結構，OSDMap更多記錄的是OSDMap的屬性(epoch/fsid/pool資訊以及osd的ip等等)。

葉子節點是device（也就是osd），其他的節點稱為bucket節點，這些bucket都是虛構的節點，可以根據實體結構進行抽象，當然樹形結構隻有一個最終的根節點稱之為root節點，中間虛拟的bucket節點可以是資料中心抽象、機房抽象、機架抽象、主機抽象等。

5.3.2 資料分布政策Placement Rules

資料分布政策Placement Rules主要有特點：

a. 從CRUSH Map中的哪個節點開始查找

b. 使用那個節點作為故障隔離域

c. 定位副本的搜尋模式（廣度優先 or 深度優先）

5.3.3 Bucket随機算法類型

ceph_bucket

• 一般的buckets：适合所有子節點權重相同，而且很少添加删除item。

• list buckets：适用于叢集擴充類型。增加item，産生最優的資料移動，查找item，時間複雜度O(n)。

• tree buckets：查找負責度是O (log n), 添加删除葉子節點時，其他節點node_id不變。

• straw buckets：允許所有項通過類似抽簽的方式來與其他項公平“競争”。定位副本時，bucket中的每一項都對應一個随機長度的straw，且擁有最長長度的straw會獲得勝利（被選中），添加或者重新計算，子樹之間的資料移動提供最優的解決方案。

5.4 CRUSH算法案例

說明：

叢集中有部分sas和ssd磁盤，現在有個業務線性能及可用性優先級高于其他業務線，能否讓這個高優業務線的資料都存放在ssd磁盤上。

普通使用者：

ceph_sas.png

高優使用者：

ssd

配置規則：

ceph_crush1

6. 定制化Ceph RBD QOS

6.1 QOS介紹

QoS （Quality of Service，服務品質）起源于網絡技術，它用來解決網絡延遲和阻塞等問題，能夠為指定的網絡通信提供更好的服務能力。

問題：

我們總的Ceph叢集的iIO能力是有限的，比如帶寬，IOPS。如何避免使用者争取資源，如果保證叢集所有使用者資源的高可用性，以及如何保證高優使用者資源的可用性。是以我們需要把有限的IO能力合理配置設定。

6.2 Ceph IO操作類型

• ClientOp：來自用戶端的讀寫I/O請求。

• SubOp：osd之間的I/O請求。主要包括由用戶端I/O産生的副本間資料讀寫請求，以及由資料同步、資料掃描、負載均衡等引起的I/O請求。

• SnapTrim：快照資料删除。從用戶端發送快照删除指令後，删除相關中繼資料便直接傳回，之後由背景線程删除真實的快照資料。通過控制snaptrim的速率間接控制删除速率。

• Scrub：用于發現對象的靜默資料錯誤，掃描中繼資料的Scrub和對象整體掃描的deep Scrub。

• Recovery：資料恢複和遷移。叢集擴/縮容、osd失效/從新加入等過程。

6.3 Ceph 官方QOS原理

ceph_mclok_qos

mClock是一種基于時間标簽的I/O排程算法，最先被Vmware提出來的用于集中式管理的存儲系統。(目前官方QOS子產品屬于半成品)。

基本思想：

• reservation 預留，表示用戶端獲得的最低I/O資源。
• weight 權重，表示用戶端所占共享I/O資源的比重。
• limit 上限，表示用戶端可獲得的最高I/O資源。

6.4 定制化QOS原理

6.4.1 令牌桶算法介紹

ceph_token_qos

基于令牌桶算法(TokenBucket)實作了一套簡單有效的qos功能，滿足了雲平台使用者的核心需求。

基本思想：

• 按特定的速率向令牌桶投放令牌。

• 根據預設的比對規則先對封包進行分類，不符合比對規則的封包不需要經過令牌桶的處理，直接發送。

• 符合比對規則的封包，則需要令牌桶進行處理。當桶中有足夠的令牌則封包可以被繼續發送下去，同時令牌桶中的令牌量按封包的長度做相應的減少。

• 當令牌桶中的令牌不足時，封包将不能被發送，隻有等到桶中生成了新的令牌，封包才可以發送。這就可以限制封包的流量隻能是小于等于令牌生成的速度，達到限制流量的目的。

6.4.2 RBD令牌桶算法流程

ceph_token1

步驟：

• 使用者發起請求異步IO到達Image中。
• 請求到達ImageRequestWQ隊列中。
• 在ImageRequestWQ出隊列的時候加入令牌桶算法TokenBucket。
• 通過令牌桶算法進行限速，然後發送給ImageRequest進行處理。

6.4.3 RBD令牌桶算法架構圖

現有架構圖：

ceph_qos2

令牌圖算法架構圖：

ceph_qos_token2

作者：李航，多年的底層開發經驗，在高性能nginx開發和分布式緩存redis cluster有着豐富的經驗，目前從事Ceph工作兩年左右。先後在58同城、汽車之家、優酷洋芋集團工作。 目前供職于滴滴基礎平台運維部 負責分布式Ceph叢集開發及運維等工作。個人主要關注的技術領域：高性能Nginx開發、分布式緩存、分布式存儲。

出處：https://www.jianshu.com/p/cc3ece850433

版權申明：内容來源網絡，版權歸原創者所有。除非無法确認，我們都會标明作者及出處，如有侵權煩請告知，我們會立即删除并表示歉意。謝謝。

posted on 2018-12-06 16:29  飛飛飛——998 閱讀( ...) 評論( ...) 編輯 收藏

轉載于:https://www.cnblogs.com/fengdaye/p/10077455.html