容忍網(wǎng)絡抖動：
Monitor 收到 OSD 對其伙伴 OSD 的匯報后刻盐，并沒有馬上將目標 OSD 下線掏膏，而是周期性的等待幾個條件：
a. 目標 OSD 的失效時間大于通過固定量 osd_heartbeat_grace 和歷史網(wǎng)絡條件動態(tài)確定的閾值。
b. 來自不同主機的匯報達到 mon_osd_min_down_reporters敦锌。
c. 滿足前兩個條件前失效匯報沒有被源 OSD 取消馒疹。

擴散：
作為中心節(jié)點的 Monitor 并沒有在更新 OSDMap 后嘗試廣播通知所有的 OSD 和 Client，而是惰性的等待 OSD 和 Client 來獲取乙墙。以此來減少 Monitor 壓力并簡化交互邏輯颖变。

4. Ceph 通信框架

4.1 Ceph 通信框架種類介紹

網(wǎng)絡通信框架三種不同的實現(xiàn)方式：

Simple 線程模式
特點：每一個網(wǎng)絡鏈接，都會創(chuàng)建兩個線程听想，一個用于接收腥刹，一個用于發(fā)送。
缺點：大量的鏈接會產(chǎn)生大量的線程汉买，會消耗 CPU 資源衔峰，影響性能。

Async 事件的I/O多路復用模式
特點：這種是目前網(wǎng)絡通信中廣泛采用的方式。k版默認已經(jīng)使用 Asnyc 了垫卤。

XIO 方式使用了開源的網(wǎng)絡通信庫 accelio 來實現(xiàn)
特點：這種方式需要依賴第三方的庫 accelio 穩(wěn)定性威彰，目前處于試驗階段。

4.2 Ceph 通信框架設計模式

設計模式（Subscribe/Publish）：
訂閱發(fā)布模式又名觀察者模式穴肘，它意圖是“定義對象間的一種一對多的依賴關系歇盼，當一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新”评抚。

4.3 Ceph 通信框架流程圖

image.png

步驟：
a. Accepter 監(jiān)聽 peer 的請求豹缀，調(diào)用 SimpleMessenger::add_accept_pipe（） 創(chuàng)建新的 Pipe 到 SimpleMessenger::pipes 來處理該請求。
b. Pipe 用于消息的讀取和發(fā)送慨代。該類主要有兩個組件邢笙，Pipe::Reader，Pipe::Writer 用來處理消息讀取和發(fā)送鱼响。
c. Messenger 作為消息的發(fā)布者鸣剪，各個 Dispatcher 子類作為消息的訂閱者组底，Messenger 收到消息之后丈积，通過 Pipe 讀取消息，然后轉(zhuǎn)給 Dispatcher 處理债鸡。
d. Dispatcher 是訂閱者的基類江滨，具體的訂閱后端繼承該類,初始化的時候通過 Messenger::add_dispatcher_tail/head 注冊到 Messenger::dispatchers. 收到消息。
e. DispatchQueue 該類用來緩存收到的消息厌均，然后喚醒 DispatchQueue::dispatch_thread 線程找到后端的 Dispatch 處理消息唬滑。

image.png

4.4 Ceph 通信框架類圖

image.png

4.5 Ceph 通信數(shù)據(jù)格式

通信協(xié)議格式需要雙方約定數(shù)據(jù)格式。

消息的內(nèi)容主要分為三部分：

• header //消息頭棺弊，類型消息的信封
• user data //需要發(fā)送的實際數(shù)據(jù)
  • payload //操作保存元數(shù)據(jù)
  • middle //預留字段
  • data //讀寫數(shù)據(jù)
• footer //消息的結(jié)束標記

class Message : public RefCountedObject {
protected:
  ceph_msg_header  header;      // 消息頭
  ceph_msg_footer  footer;      // 消息尾
  bufferlist       payload;  // "front" unaligned blob
  bufferlist       middle;   // "middle" unaligned blob
  bufferlist       data;     // data payload (page-alignment will be preserved where possible)  

  /* recv_stamp is set when the Messenger starts reading the
   * Message off the wire */
  utime_t recv_stamp;       //開始接收數(shù)據(jù)的時間戳    
  /* dispatch_stamp is set when the Messenger starts calling dispatch() on  
   * its endpoints */
  utime_t dispatch_stamp;   //dispatch 的時間戳
  /* throttle_stamp is the point at which we got throttle */
  utime_t throttle_stamp;   //獲取throttle 的slot的時間戳
  /* time at which message was fully read */
  utime_t recv_complete_stamp;  //接收完成的時間戳
  ConnectionRef connection;     //網(wǎng)絡連接
  uint32_t magic = 0;           //消息的魔術字
  bi::list_member_hook<> dispatch_q;  //boost::intrusive 成員字段
};

struct ceph_msg_header {
    __le64 seq;       // 當前session內(nèi) 消息的唯一序號
    __le64 tid;        // 消息的全局唯一的 id   
    __le16 type;       // 消息類型
    __le16 priority;    // 優(yōu)先級
__le16 version;    // 版本號

    __le32 front_len;   // payload 的長度
    __le32 middle_len;  // middle 的長度
    __le32 data_len;    // data 的長度
    __le16 data_off;    // 對象的數(shù)據(jù)偏移量
    
    
    struct ceph_entity_name src;    //消息源
    
    /* oldest code we think can decode this.  unknown if zero. */
    __le16 compat_version;  
    __le16 reserved;
    __le32 crc;       /* header crc32c */
} __attribute__ ((packed));


struct ceph_msg_footer {
    __le32 front_crc, middle_crc, data_crc; //crc校驗碼
    __le64  sig; //消息的64位signature
    __u8 flags; //結(jié)束標志
} __attribute__ ((packed));

5. Ceph CRUSH 算法

5.1 數(shù)據(jù)分布算法挑戰(zhàn)

數(shù)據(jù)分布和負載均衡：

• 數(shù)據(jù)分布均衡晶密，使數(shù)據(jù)能均勻的分布到各個節(jié)點上。
• 負載均衡模她，使數(shù)據(jù)訪問讀寫操作的負載在各個節(jié)點和磁盤的負載均衡稻艰。

靈活應對集群伸縮：

• 系統(tǒng)可以方便的增加或者刪除節(jié)點設備，并且對節(jié)點失效進行處理侈净。
• 增加或者刪除節(jié)點設備后尊勿，能自動實現(xiàn)數(shù)據(jù)的均衡，并且盡可能少的遷移數(shù)據(jù)畜侦。

支持大規(guī)模集群：

• 要求數(shù)據(jù)分布算法維護的元數(shù)據(jù)相對較小元扔，并且計算量不能太大。隨著集群規(guī)模的增 加旋膳，數(shù)據(jù)分布算法開銷相對比較小澎语。

5.2 Ceph CRUSH 算法說明

CRUSH 算法的全稱為：Controlled Scalable Decentralized Placement of Replicated Data，可控的、可擴展的擅羞、分布式的副本數(shù)據(jù)放置算法盯孙。

PG到OSD 的映射的過程算法叫做 CRUSH 算法。（一個 Object 需要保存三個副本祟滴，也就是需要保存在三個 osd 上）振惰。

CRUSH 算法是一個偽隨機的過程，他可以從所有的 OSD 中垄懂，隨機性選擇一個 OSD 集合骑晶，但是同一個 PG 每次隨機選擇的結(jié)果是不變的，也就是映射的 OSD 集合是固定的草慧。

5.3 Ceph CRUSH 算法原理

CRUSH 算法因子：

• 層次化的 Cluster Map
  反映了存儲系統(tǒng)層級的物理拓撲結(jié)構(gòu)桶蛔。定義了 OSD 集群具有層級關系的靜態(tài)拓撲結(jié)構(gòu)。OSD 層級使得 CRUSH 算法在選擇 OSD 時實現(xiàn)了機架感知能力漫谷，也就是通過規(guī)則定義仔雷， 使得副本可以分布在不同的機 架、不同的機房中舔示、提供數(shù)據(jù)的安全性 碟婆。

• Placement Rules
  決定了一個 PG 的對象副本如何選擇的規(guī)則，通過這些可以自己設定規(guī)則惕稻，用戶可以自定義設置副本在集群中的分布竖共。

5.3.1 層級化的 Cluster Map

image.png

CRUSH Map 是一個樹形結(jié)構(gòu)，OSDMap 更多記錄的是 OSDMap 的屬性（epoch/fsid/pool 信息以及 osd 的 ip 等等）俺祠。

葉子節(jié)點是 device（也就是 osd）公给，其他的節(jié)點稱為 bucket 節(jié)點，這些 bucket 都是虛構(gòu)的節(jié)點蜘渣，可以根據(jù)物理結(jié)構(gòu)進行抽象淌铐，當然樹形結(jié)構(gòu)只有一個最終的根節(jié)點稱之為 root 節(jié)點，中間虛擬的 bucket 節(jié)點可以是數(shù)據(jù)中心抽象蔫缸、機房抽象腿准、機架抽象、主機抽象等捂龄。

5.3.2 數(shù)據(jù)分布策略 Placement Rules

數(shù)據(jù)分布策略 Placement Rules 主要有特點：

• 從 CRUSH Map 中的哪個節(jié)點開始查找
• 使用那個節(jié)點作為故障隔離域
• 定位副本的搜索模式（廣度優(yōu)先 or 深度優(yōu)先）

rule replicated_ruleset  #規(guī)則集的命名释涛，創(chuàng)建pool時可以指定rule集
{
    ruleset 0                             # rules集的編號，順序編即可 
    type replicated                       # 定義pool類型為replicated（還有erasure模式）
    min_size 1                            # pool中最小指定的副本數(shù)量不能小1
    max_size 10                           # pool中最大指定的副本數(shù)量不能大于10
    step take default                     # 查找bucket入口點倦沧，一般是root類型的bucket
    step chooseleaf firstn 0 type host    #選擇一個host,并遞歸選擇葉子節(jié)點osd
    step emit                             # 結(jié)束
}

5.3.3 Bucket 隨機算法類型

image.png

• 一般的 buckets：適合所有子節(jié)點權重相同唇撬，而且很少添加刪除 item。
• list buckets：適用于集群擴展類型展融。增加 item窖认，產(chǎn)生最優(yōu)的數(shù)據(jù)移動，查找 item，時間復雜度 O（n）扑浸。
• tree buckets：查找負責度是 O （log n）烧给，添加刪除葉子節(jié)點時，其他節(jié)點 node_id 不變喝噪。
• straw buckets：允許所有項通過類似抽簽的方式來與其他項公平“競爭”础嫡。定位副本時，bucket 中的每一項都對應一個隨機長度的 straw酝惧，且擁有最長長度的 straw 會獲得勝利（被選中）榴鼎，添加或者重新計算，子樹之間的數(shù)據(jù)移動提供最優(yōu)的解決方案晚唇。

5.4 Ceph CRUSH 算法案例

說明：
集群中有部分 sas 和 ssd 磁盤巫财，現(xiàn)在有個業(yè)務線性能及可用性優(yōu)先級高于其他業(yè)務線，能否讓這個高優(yōu)業(yè)務線的數(shù)據(jù)都存放在 ssd 磁盤上哩陕。

普通用戶：

image.png

高優(yōu)用戶：

image.png

配置規(guī)則：

image.png

6. 定制化 Ceph RBD QOS

6.1 QOS 介紹

QoS （Quality of Service平项，服務質(zhì)量）起源于網(wǎng)絡技術，它用來解決網(wǎng)絡延遲和阻塞等問題悍及，能夠為指定的網(wǎng)絡通信提供更好的服務能力闽瓢。

問題：
我們總的 Ceph 集群的 IO 能力是有限的，比如帶寬并鸵，IOPS鸳粉。如何避免用戶爭搶資源扔涧，如何保證集群所有用戶資源的高可用性园担，以及如何保證高優(yōu)用戶資源的可用性。所以我們需要把有限的 IO 能力合理分配枯夜。

6.2 Ceph IO 操作類型

ClientOp：來自客戶端的讀寫 I/O 請求弯汰。
SubOp：osd 之間的 I/O 請求。主要包括由客戶端 I/O 產(chǎn)生的副本間數(shù)據(jù)讀寫請求湖雹，以及由數(shù)據(jù)同步咏闪、數(shù)據(jù)掃描、負載均衡等引起的 I/O 請求摔吏。
SnapTrim：快照數(shù)據(jù)刪除鸽嫂。從客戶端發(fā)送快照刪除命令后，刪除相關元數(shù)據(jù)便直接返回征讲，之后由后臺線程刪除真實的快照數(shù)據(jù)据某。通過控制 snaptrim 的速率間接控制刪除速率。
Scrub：用于發(fā)現(xiàn)對象的靜默數(shù)據(jù)錯誤诗箍，掃描元數(shù)據(jù)的 Scrub 和對象整體掃描的 deep Scrub癣籽。
Recovery：數(shù)據(jù)恢復和遷移。集群擴/縮容、osd 失效/從新加入等過程筷狼。

6.3 Ceph 官方 QOS 原理

image.png

mClock 是一種基于時間標簽的 I/O 調(diào)度算法瓶籽，最先被 Vmware 提出來的用于集中式管理的存儲系統(tǒng)。（目前官方 QOS 模塊屬于半成品）埂材。

基本思想：

• reservation 預留塑顺，表示客戶端獲得的最低 I/O 資源。
• weight 權重俏险，表示客戶端所占共享 I/O 資源的比重茬暇。
• limit 上限，表示客戶端可獲得的最高 I/O 資源寡喝。

6.4 定制化 QOS 原理

6.4.1 令牌桶算法介紹

image.png

基于令牌桶算法（TokenBucket）實現(xiàn)了一套簡單有效的 qos 功能糙俗，滿足了云平臺用戶的核心需求。

基本思想：
a. 按特定的速率向令牌桶投放令牌预鬓。
b. 根據(jù)預設的匹配規(guī)則先對報文進行分類巧骚，不符合匹配規(guī)則的報文不需要經(jīng)過令牌桶的處理，直接發(fā)送格二。
c. 符合匹配規(guī)則的報文劈彪，則需要令牌桶進行處理。當桶中有足夠的令牌則報文可以被繼續(xù)發(fā)送下去顶猜，同時令牌桶中的令牌量按報文的長度做相應的減少沧奴。
d. 當令牌桶中的令牌不足時，報文將不能被發(fā)送长窄，只有等到桶中生成了新的令牌滔吠，報文才可以發(fā)送。這就可以限制報文的流量只能是小于等于令牌生成的速度挠日，達到限制流量的目的疮绷。

6.4.2 RBD 令牌桶算法流程

image.png

步驟：
a. 用戶發(fā)起請求異步IO到達Image中。
b. 請求到達ImageRequestWQ隊列中嚣潜。
c. 在ImageRequestWQ出隊列的時候加入令牌桶算法TokenBucket冬骚。
d. 通過令牌桶算法進行限速，然后發(fā)送給ImageRequest進行處理懂算。

6.4.3 RBD令牌桶算法框架圖

現(xiàn)有框架圖：

image.png

令牌圖算法框架圖：

image.png

整理中....