2. 程式人生 > >Ceph架構原理及使用場景介紹

Ceph架構原理及使用場景介紹

阿新 • • 發佈：2018-11-14

本文是滴滴雲開源框架教程系列文章的一篇。

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.png

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.png

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

主要是將裸磁碟空間對映給主機使用的。

優點：

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

缺點：

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

使用場景：

  • Docker容器、虛擬機器磁碟儲存分配。
  • 日誌儲存。
  • 檔案儲存。
  • …

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

fs.png

典型裝置： FTP、NFS伺服器
為了克服塊儲存檔案無法共享的問題，所以有了檔案儲存。
在伺服器上架設FTP與NFS服務，就是檔案儲存。

優點：

  • 造價低，隨便一臺機器就可以了。
  • 方便檔案共享。

缺點：

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

使用場景：

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

1.7 三種儲存型別-物件儲存

rgw.png

典型裝置： 內建大容量硬碟的分散式伺服器(Swift, S3)
多臺伺服器內建大容量硬碟，安裝上物件儲存管理軟體，對外提供讀寫訪問功能。

優點：

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

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

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

2. Ceph IO流程及資料分佈

rados_io_1.png

2.1 正常IO流程圖

ceph_io_2.png

步驟：

  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.png

步驟：

  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.png

  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虛擬碼流程

locator = object_name
obj_hash =  hash(locator)
pg = obj_hash % num_pg
osds_for_pg = crush(pg)    # returns a list of osds
primary = osds_for_pg[0]
replicas = osds_for_pg[1:]

2.5 Ceph RBD IO流程

ceph_rbd_io.png

步驟：

  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.png

客戶端寫資料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.png

說明：

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

2.8 Ceph 資料擴容PG分佈

場景資料遷移流程：

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

現狀：
ceph_recory_1.png

擴容後：
ceph_io_recry2.png

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

3. Ceph心跳機制

3.1 心跳介紹

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

問題：

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

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

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

3.2 Ceph 心跳檢測

ceph_heartbeat_1.png

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

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

3.3 Ceph OSD之間相互心跳檢測

ceph_heartbeat_osd.png

步驟：

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

3.4 Ceph OSD與Mon心跳檢測

ceph_heartbeat_mon.png

OSD報告給Monitor：

  • OSD有事件發生時（比如故障、PG變更）。
  • 自身啟動5秒內。
  • OSD週期性的上報給Monitor
    • 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.png

步驟：

  • 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.png

4.4 Ceph通訊框架類圖

ceph_message_3.png

4.5 Ceph通訊資料格式

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

訊息的內容主要分為三部分：

  • header //訊息頭，型別訊息的信封
  • user data //需要傳送的實際資料
    • payload //操作儲存元資料
    • middle //預留欄位
    • data //讀寫資料
  • footer //訊息的結束標記
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;		//開始接收資料的時間戳
  /* 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;		//網路連線

  uint32_t magic = 0;			//訊息的魔術字

  bi::list_member_hook<> dispatch_q;	//boost::intrusive 成員欄位
};

struct ceph_msg_header {
	__le64 seq;       // 當前session內訊息的唯一序號
	__le64 tid;       // 訊息的全域性唯一的 id
	__le16 type;      // 訊息型別
	__le16 priority;  // 優先順序
	__le16 version;   // 版本號

	__le32 front_len; // payload 的長度
	__le32 middle_len;// middle 的長度
	__le32 data_len;  // data 的長度
	__le16 data_off;  // 物件的資料偏移量


	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; //結束標誌
} __attribute__ ((packed));

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.png

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 深度優先）

rule replicated_ruleset  #規則集的命名，建立pool時可以指定rule集
{
    ruleset 0                #rules集的編號，順序編即可   
    type replicated          #定義pool型別為replicated(還有erasure模式)   
    min_size 1                #pool中最小指定的副本數量不能小1
    max_size 10               #pool中最大指定的副本數量不能大於10       
    step take default         #查詢bucket入口點，一般是root型別的bucket    
    step chooseleaf  firstn  0  type  host #選擇一個host,並遞迴選擇葉子節點osd     
    step emit        #結束
}

5.3.3 Bucket隨機演算法型別

ceph_bucket.png

  • 一般的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.png

配置規則：
ceph_crush1.png

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.png

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

基本思想：

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

6.4 定製化QOS原理

6.4.1 令牌桶演算法介紹

ceph_token_qos.png

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

基本思想：

  • 按特定的速率向令牌桶投放令牌。
  • 根據預設的匹配規則先對報文進行分類，不符合匹配規則的報文不需要經過令牌桶的處理，直接傳送。
  • 符合匹配規則的報文，則需要令牌桶進行處理。當桶中有足夠的令牌則報文可以被繼續傳送下去，同時令牌桶中的令牌量按報文的長度做相應的減少。
  • 當令牌桶中的令牌不足時，報文將不能被髮送，只有等到桶中生成了新的令牌，報文才可以傳送。這就可以限制報文的流量只能是小於等於令牌生成的速度，達到限制流量的目的。

6.4.2 RBD令牌桶演算法流程

ceph_token1.png

步驟：

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

6.4.3 RBD令牌桶演算法框架圖

現有框架圖：
ceph_qos2.png

令牌圖演算法框架圖：
ceph_qos_token2.png

滴滴基礎平臺運維部和滴滴雲儲存技術團隊在分散式儲存方面積累了豐富的經驗，敬請關注本系列文章的後續分享。

作者資訊

作者：李航
個人簡介：滴滴基礎平臺運維部技術專家，主要負責分散式Ceph系統。曾在58同城、汽車之家、優酷土豆集團工作多年，在高效能Nginx開發和分散式快取Redis cluster等方面有著豐富的經驗。

相關推薦

Ceph架構原理及使用場景介紹

本文是滴滴雲開源框架教程系列文章的一篇。 1.1 Ceph簡介 Ceph是一個統一的分散式儲存系統，設計初衷是提供較好的效能、可靠性和可擴充套件性。 Ceph專案最早起源於Sage就讀博士期間的工作（最早的成果於2004年發表），並隨後貢獻給開源社群。在經過了數年的發展之後，目前

（2）LVS+Keepalived高可用負載均衡架構原理及配置

LVS Keepalived1、keepalived 介紹2、keepalived 優缺點3、keepalived 應用場景4、keepalived 安裝配置5、keepalived+lvs 高可用6、keepalived+nginx 高可用7、keepalived 切換原理8、性能優化9、常見故障 一、k

Nginx工作原理及相關介紹

handle 利用 ice fff 高並發 解析器 異常 creat 為什麽 Nginx工作原理及相關介紹一、Nginx工作原理與模塊介紹1、Nginx基本工作原理NGINX以高性能的負載均衡器，緩存，和web服務器聞名。Nginx由內核和模塊組成，其中，內核的設計非常微小

RocketMQ架構原理及名詞概念（三）

這節主要講述RocketMQ的整體架構，和常用術語解釋。當我們接觸一個新東西的時候，一定要知道他的原理，只有知道原理之後，才會產生問題。只有帶著問題去讀原始碼才會事半功倍。 首先盜用官方的一張圖片：（官方地址：http://rocketmq.apache.org/） NameServer：從上圖可以清

電子商城後臺系統（二）：系統架構設計及系統介紹

在寫一個程式之前，需要在大腦中對整個系統有一個初步的規劃，對於系統的功能模組，通常來說需要劃分成三大塊：框架部分、核心業務部分、擴充套件業務部分。 框架部分，通常是用來放通用的工具類方法，還有通用的處理資料、業務的方法，這些方法一般與系統的業務無關。電子商城的後臺系統，通常都會有許可權管理模組，

LNMP架構原理及基礎運用部署

LNMP架構原理及基礎運用 LNMP資料傳輸原理 使用者通過http協議發起請求，請求會先抵達LNMP架構中的Nginx Nginx根據使用者的請求進行判斷，該判斷由Location進行完成（靜態請求走本地，動態請求交給後端）。 判斷使用者請求為靜態頁面，Ng

Android Multimedia框架總結（七）C++中MediaPlayer的C/S架構補充及MediaService介紹

前面一篇主要介紹c++中MediaPlayer的C/S架構中和Client相關部分，並中間穿插了mediaplayerservice的部分。但是對於這塊C/S部分，沒有放大去分析。《Android Multimedia框架總結（四）MediaPlayer中從

介面卡模式原理及例項介紹

本文首先介紹了介面卡模式的基本實現原理，然後通過一個例項讓讀者從程式碼的角度快速瞭解介面卡模式的執行方式，接著對介面卡模式在 JDK 中的應用做了一些介紹，最後對介面卡模式的兩種實現方式區別、優缺點、應用場景等做了一定的總結。 介面卡模式基本介紹 著名的設計模式“

EasyScheduler調度系統的架構原理及實現思路

png nmp dag login spark 註意 健康 tar tro 系統架構設計 在對調度系統架構說明之前，我們先來認識一下調度系統常用的名詞 1.名詞解釋 DAG： 全稱Directed Acyclic Graph，簡稱DAG。工作流中的Task任務以有向無環圖的

Docker 架構原理及簡單使用

　　提示：文中有些內容為大神的部落格內容，就不統一標註那裡引用，只是再最下面標註參考連線謝謝 一、簡介 　　1、瞭解docker的前生LXC 　　　　　LXC為Linux Container的簡寫。可以提供輕量級的虛擬化，以便隔離程序和資源，而且不需要提供指令解釋機制以及全虛擬化的其他複雜性。相當於C+

GPS北斗NTP校時伺服器原理及功能介紹

  在科技的發展下GPS北斗NTP校時伺服器也得到了廣泛應用，比如工業、科研、航空航天、公共場所等領域都用到了GPS北斗NTP校時伺服器，該時間伺服器以衛星時間為基準授時準確，替代了傳統鐘錶授時的單一和時間誤差大等缺點。 GPS北斗NTP校時伺服器，是指接收GPS北斗衛星訊號，並通過NTP網路協議進

RocketMQ(1)---架構原理及環境搭建

一、架構簡述 RocketMQ阿里開源的一個分散式訊息傳遞和流媒體平臺，具有低延遲，高效能和可靠性， 萬億級容量和靈活的可伸縮性。跟其它中介軟體相比，RocketMQ的特點是純JAVA實現,在發生宕機和其它故障時訊息丟失率更低。 它由四個部分組成：nameserver，broker，生產者和消費者。它們中的每

3-1-企業級架構拓展思路及集群負載均衡場景介紹

計算 單個 poi sql 文件系統 虛擬 server 瀏覽記錄 圖片 單主機不僅受限於硬件性能也受限於並發模型，select()1024scale up向上擴展，用性能更好的主機代替性能略差的主機scale out向外擴展，多加主機，分割任務，將任務分散處理，這叫做負載

zabbix實現原理及架構詳解

收集 信息 核心 狀態 start 原理 整體架構 比較 zabbix 想要用好zabbix進行監控，那麽我們首要需要了解下zabbix這個軟件的實現原理及它的架構。建議多閱讀官方文檔。 一、總體上zabbix的整體架構如下圖所示： 重要組件說明： 1）zabbix se

高性能Mysql主從架構的復制原理及配置詳解

應用場景 難點 要點 一行 tar distrib 控制 成功 實時性 1 復制概述 Mysql內建的復制功能是構建大型，高性能應用程序的基礎。將Mysql的數據分布到多個系統上去，這種分布的機制，是通過將Mysql的某一臺主機的數據復制到其它主機（slaves

Docker五種存儲驅動原理及應用場景和性能測試對比

Docker 存儲驅動 Docker最開始采用AUFS作為文件系統，也得益於AUFS分層的概念，實現了多個Container可以共享同一個image。但由於AUFS未並入Linux內核，且只支持Ubuntu，考慮到兼容性問題，在Docker 0.7版本中引入了存儲驅動， 目前，Docker支持AUFS

消息中間件的原理及架構框架

ora stc 過程 per 解決 smo 客戶端 cto webkit 消息中間件就是在消息的傳輸過程中保存消息的容器。消息中間件再將消息從它的源中繼到它的目標時充當中間人的作用。隊列的主要目的是提供路由並保證消息的傳遞；如果發送消息時接收者不可用，消息隊列會保留消息，直

【Ceph系列01】Ceph的工作原理及流程

-o 尋址 ofo color proc 分享圖片 tac ges sha 首先我們了解一下Ceph系統中的尋址流程，如下圖所示： 本文部分參考來自 http://www.csdn.net/article/2014-04-08/2819192-ceph-swift-on

mybatis原理，配置介紹及原始碼分析

前言 mybatis核心元件有哪些？它是工作原理是什麼？ mybatis配置檔案各個引數是什麼含義？ mybatis只添加了介面類，沒有實現類，為什麼可以直接查詢呢？ mybatis的mapper對映檔案各個引數又是什麼含義？ mybatis-spring提供哪些機制簡化了原生mybatis？ m

Memcached學習筆記之六：memcached高可用叢集原理及介紹

首先我要宣告的是為什麼叫分散式叢集？ 因為我們要達到的目的是要把快取放到2臺搭建在不同的伺服器上面的memcached，所以我們如果兩個memcached中放的是一樣的資料，那麼就是叢集，如果是根據業務不同而放不一樣的資料就是分散式！ memcached在實現分散式群集部署時，memcached