ceph體系架構總覽

1、功能劃分

Ceph的提供了一個根據RADOS無限擴展的Ceph存儲集羣，相關內容你能夠參閱REDOS-一個可伸縮的、可靠的存儲服務PB級別存儲集羣。存儲集 羣客戶端和每一個Ceph的OSD守護進程使用CRUSH算法有效地計算有關數據位置的信息，而沒必要依賴於一個查找表。Ceph的高層次功能包括Ceph的 存儲集羣，經過 librados提供了一個原生接口，在librados基礎上創建一些服務接口。

對應的進程Monitors監視器（ceph-mon），OSDs對象存儲設備（ceph-osd）,經過讀取配置文件ceph.conf實現集羣。

1.1 OSD功能

OSD能夠被抽象爲兩個組成部分，即系統部分和守護進程（OSD deamon）部分。OSD的系統部分本質上就是一臺安裝了操做系統和文件系統的計算機，其硬件部分至少包括一個單核的處理器、必定數量的內存、一塊硬盤以及一張網卡。系統部分由操做系統內核實現，爲ceph提供接口。

在 RADOS 的運行過程當中， cluster map 的更新徹底取決於系統的狀態變化，而致使這一變化的常見事件只有兩種： OSD 出現故障，或者 RADOS 規模擴大。 Cluster Maps 指包含全部的 Map ： OSD map,monitor map,placement group map, metadata server map 。

1.2 OSD管理的PG

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映射：其映射十分簡單，本質上就是按照object的最大size對file進行切分，至關於RAID中的條帶化過程。這種切分的好處有二：一是讓大小不限的 file變成最大size一致、能夠被RADOS高效管理的object；二是讓對單一file實施的串行處理變爲對多個object實施的並行化處理。

Object -> PG映射：在file被映射爲一個或多個object以後，就須要將每一個object獨立地映射到一個PG中去。

PG -> OSD映射：第三次映射就是將做爲object的邏輯組織單元的PG映射到數據的實際存儲單元OSD。

注意：映射過程當中使用cluster map中的placement group map，OSDmap。

在 Ceph的現有機制中，一個OSD平時須要和與其共同承載同一個PG的其餘OSD交換信息，以肯定各自是否工做正常，是否須要進行維護操做。因爲一個 OSD上大約承載數百個PG，每一個PG內一般有3個OSD，所以，一段時間內，一個OSD大約須要進行數百至數千次OSD信息交換。

1.3 OSD的狀態變遷

OSD狀態的描述分爲兩個維度：up或者down（代表OSD是否正常工做），in或者out（代表OSD是否在至少一個PG中）。所以，對於任意一個OSD，共有四種可能的狀態：

A．Up且in：說明該OSD正常運行，且已經承載至少一個PG的數據。這是一個OSD的標準工做狀態；

B. Up且out：說明該OSD正常運行，但並未承載任何PG，其中也沒有數據。一個新的OSD剛剛被加入Ceph集羣后，便會處於這一狀態。而一個出現故障的OSD被修復後，從新加入Ceph集羣時，也是處於這一狀態；

C. Down且in：說明該OSD發生異常，但仍然承載着至少一個PG，其中仍然存儲着數據。這種狀態下的OSD剛剛被發現存在異常，可能仍能恢復正常，也可能會完全沒法工做；

D. Down且out：說明該OSD已經完全發生故障，且已經再也不承載任何PG。

1.4 OSD的心跳維持

心跳是用於OSD節點間檢測對方是否故障的，以便及時發現故障節點進入相應的故障處理流程。故障檢測須要在故障的發現時間和心跳帶來的負載之間作權衡，若是心跳頻率過高則過多的心跳報文會影響系統性能，若是心跳頻率太低則會延長髮現故障節點的時間，從而影響系統的可用性。

在大規模部署的場景中，若是任意兩個OSD節點間都創建心跳鏈接將帶來巨大的負擔。尤爲，當新加入一個OSD節點時這個負擔就會幾倍地增長。Ceph中每一個OSD只和如下兩類節點創建心跳鏈接： 一類是同個PG下的OSD節點之間，由於屬於同個PG的OSD節點會保存同份數據的副本，如若出現故障則會直接影響數據的可用性。另外一類是OSD的左右兩 個相鄰的節點，這兩個節點同本身物理上存在比較緊密的聯繫，例如可能鏈接在同臺交換機。另外，若是創建心跳的Peer數目少於 osd_heartbeat_min_peers，那麼OSD會繼續同離他較近的幾個OSD創建心跳鏈接。

OSD節點會監聽public、cluster、front和back四個端口，其中front和back兩個端口都是用於心跳的，cluster 端口用來監聽來自OSD Peer的鏈接，public用來監聽來自Monitor和Client的鏈接。若是啓動OSD時沒有提供back的IP地址，則back使用 cluster的IP地址；而front不單獨提供IP地址，直接使用public的IP地址。另外，OSD單首創建了一個名爲hbclient的 Messenger，做爲心跳的客戶端，單獨用來創建鏈接發送心跳報文。心跳報文優先發送給back鏈接。

代碼註釋

// ceph-osd.cc 啓動osd時建立Messengers

OSD::maybe_update_heartbeat_peers() 肯定同哪些peer創建心跳鏈接，剔除已經down掉的節點的心跳鏈接

OSD::_add_heartbeat_peer()  同給定的peer創建心跳鏈接

OSDServeice::get_con_osd_hb()  獲取peer的front和back鏈接

配置

OPTION(public_network, OPT_STR, "")

OPTION(cluster_network, OPT_STR, "")

OPTION(osd_heartbeat_min_peers, OPT_INT, 10)     // minimum number of peers

檢測故障

OSD使用T_Heartbeat線程定時向Peer OSDs發送心跳報文，發送報文的時間間隔在0.5~6.5之間，由osd_heartbeat_interval配置選項決定。心跳報文會同時向 Peer OSD的front和back端口發送。心跳報文分兩種類型一種是Ping類型，另外一種是Reply類型。Ping類型的報文是OSD主動發送給Peer OSD的報文，而Reply是Peer OSD迴應給本身的報文。兩種類型的心跳報文都攜帶時間戳，但它們的時間戳表明的含義不同。Ping類型報文的時間戳是發送報文時的時間，而Reply 類型報文的時間戳是從Ping報文中讀取出來的，不是表明它本身的發送時間而是表明它對應的Ping報文的發送時間。OSD接收到Reply報文時將記錄 報文的時間戳，並以此來判斷是否超時。

對每一個Peer節點，若是其最近的應答的時間(最近的Reply報文的時間戳)位於cutoff以前(即超時grace秒)，則將其加入到 failure_queue隊列。OSD會定時向Monitor彙報本身的狀態，在彙報狀態時將failure_queue隊列中Peer發送給 Monitor，由Monitor將其標記爲down狀態。Monitor在接收到OSD對Peer的故障報告後，經過PAXOS算法決定是否將Peer OSD標記爲Down狀態。若是將Peer OSD標記爲Down狀態，那麼將更新OSD MAP，OSD接收到OSD Map更新的消息後，斷開和Peer OSD的心跳鏈接。

若是在向Monitor報告故障以後但在接收到OSD Down消息以前，再次接收到Peer OSD對心跳報文的迴應，則將Peer OSD從failure_queue隊列中移除，並通知Monitor該節點依舊存活着。

代碼註釋

void OSD::heartbeat_entry() // T_Heartbeat線程入口函數，定時向心跳Peers發送心跳報文

void OSD::heartbeat()

map<int,utime_t> failure_queue; // 檢測到peer長時間沒心跳時，將peer加入到failure_queue隊列

map<int,entity_inst_t> failure_pending; // 故障報告給Monitor的Peer OSD

void send_failures();

void send_still_alive(epoch_t epoch, const entity_inst_t &i);

void OSD::note_down_osd(int peer)

void OSD::handle_osd_ping(MOSDPing *m) // 處理MOSDPing消息

配置

OPTION(osd_heartbeat_interval, OPT_INT, 6)       // (seconds) how often we ping peers

OPTION(osd_heartbeat_grace, OPT_INT, 20)         // (seconds) how long before we decide a peer has failed

1.5 OSD流程概述

Recovery/scrub/peering