Ceph分佈式文件系統

時間 2020-01-01

原文原文鏈接

2003年加州大學Santa Cruz分校的Sage Weil專爲博士論文設計的新一代自由軟件分佈式文件系統，並於2012年4月，Sage Weil成立了Inktank公司node

2010年3月以後的linux內核中，嵌入了cephlinux

2014年4月30日，RedHat以$175million的價格收購了Inktank算法

在目前開源世界裏多樣的存儲項目中，不一樣的項目都有側重點，而它們最終都是要爲企業的IT基礎設施服務。那麼企業IT基礎設施經理們到底須要怎麼樣的存儲，它們的需求獲得知足了嗎？編程

從上圖咱們能夠了解到存儲接口需求、擴展、運維和成本構成了企業級存儲產品的四大中心。幾乎全部的存儲產品包括硬件(存儲一體機，SAN)和軟件都致力於在這個方面強調本身的優點，它們或者考慮成本，或者強調擴展性。那麼咱們來看Ceph它是如何定位本身的。vim

1. 架構

Ceph是統一存儲系統，支持三種接口：安全

Object：有原生的API，並且也兼容Swift和S3的APIbash

Block：支持精簡配置、快照、克隆服務器

File：Posix接口，支持快照網絡

Ceph也是分佈式存儲系統，它的特色以下：數據結構

高擴展性：使用普通x86服務器，支持10~1000臺服務器，支持TP到PB級的擴展

高可靠性：沒有單點故障，多數據副本，自動管理，自動修復

高性能：數據分佈均衡，並行化高，對於objects storage和block storage，不須要元數據服務器

Ceph模塊架構圖：

底層是Rados，也是Ceph實現分佈式存儲的根本，全部存儲接口都是基於Rados實現的。Rados自己就是一個對象存儲接口，它自身維護了一個集羣狀態和實現了數據分發的要求，咱們一般也講Rados稱爲Ceph Cluster，由於其上的存儲接口如CephFS都是基於其上的接口實現而已

RADOS的組件（A reliable, autonomous, distributed object storage）：

OSD: 每個disk、SSD或者RAID group或者其餘一個物理存儲設備都成爲一個OSD，主要負責存儲和查找對象，而且負責向該對象的複製節點分發和恢復。

Monitor: 維護集羣的成員和狀態，維護整個ceph集羣的全局狀態。提供強一致性的決策(相似於Zookeeper的做用)

RADOS具備很強的擴展性和可編程性，Ceph基於RADOS開發了Object Storage、Block Storage、FileSystem。Ceph另外兩個組件是：

MDS：用於保存CephFS的元數據。

RADOS Gateway：對外提供REST接口，兼容S3和Swift的API。

在傳統架構中，客戶談論到一個集中的組件（如網關，代理，API等），做爲單點進入到一個複雜的子系統。這會帶來性能和可擴展性的限制，同時引入單點故障（即，若是集中的組件出現故障，整個系統也出現故障）。
Ceph的消除了集中式網關，使客戶可以直接與Ceph的OSD守護進程進行互動。Ceph的OSD守護進程建立對象的副本，在其餘Ceph的節點上，以確保數據的安全性和的高可用性。Ceph的還採用了集羣監視器，以確保高可用性。爲了消除集中Ceph的使用這種算法叫作CRUSH。

RADOS分發策略–CRUSH算法：

Ceph的客戶端和Ceph的OSD守護進程都使用CRUSH算法來高效地對數據容器的信息需求進行計算，而沒必要依賴於一個查找表。CRUSH與舊方法相比，提供了更好的數據管理機制，使大規模清晰地將工做分配到集羣中的全部客戶端和OSD守護。CRUSH使用智能的數據複製，以確保彈性，這樣能夠更好的適合於超大規模存儲。如下各節提供更多的細節CRUSH是如何工做的。

從上圖的流程解讀RADOS是如何將對象分發到不一樣的OSD上(OSD)，首先須要瞭解Ceph定義的幾個存儲區域概念。

Pool是一個命名空間，客戶端向RADOS上存儲對象時須要指定一個Pool，Pool經過配置文件定義並能夠指定Pool的存儲OSD節點範圍和PG數量。

PG是Pool內部的概念，是對象和OSD的中間邏輯分層，對象首先會經過簡單的Hash算法來獲得其存儲的PG，這個PG和對象是肯定的。而後每個PG都有一個primary OSD和幾個Secondary OSD，對象會被分發都這些OSD上存儲，而這個分發策略稱爲CRUSH—Ceph的數據均勻分佈的核心。

須要注意的是整個CRUSH以上的流程實現都是在客戶端計算，所以客戶端自己須要保存一份Cluster Map，而這是從Monitor處得到。從這裏咱們也能夠了解到Monitor主要職責就是負責維護這份Cluster Map並保證強一致性。

CRUSH經過僞隨機算法來確保均勻的數據分佈，它的輸入是PG,Cluster State和Policy，而且保證CRUSH的Object Name同樣的狀況下，即便後二者參數發生改變也會獲得一致的讀取(注意是讀取)。而且這個CRUSH算法是可配置的，經過PG Number和Weight的指定能夠獲得不一樣的分佈策略。這個可配置的分佈策略讓Ceph的能力獲得極大增強。

RADOS的邏輯結構：

在使用RADOS系統時，大量的客戶端程序經過與OSD或者monitor的交互獲取cluster map，而後直接在本地進行計算，得出對象的存儲位置後，便直接與對應的OSD通訊，完成數據的各類操做。可見，在此過程當中，只要保證cluster map不頻繁更新，則客戶端顯然能夠不依賴於任何元數據服務器，不進行任何查表操做，便完成數據訪問流程。在RADOS的運行過程當中，cluster map的更新徹底取決於系統的狀態變化，而致使這一變化的常見事件只有兩種：OSD出現故障，或者RADOS規模擴大。而正常應用場景下，這兩種事件發生的頻率顯然遠遠低於客戶端對數據進行訪問的頻率。

羣集映射：

Ceph的使用取決於Ceph的客戶和Ceph的OSD守護集羣拓撲知識，包括5類映射

1.監控映射：

包含集羣FSID，位置，名稱地址和每一個監視器的端口。這也代表如今的時期裏，當建立映射時，而且它最後一被改變。要查看監控映射，執行以下命令

# ceph mon dump

2.OSD映射：

包含集羣FSID，當建立和最後修改映射時間，池的列表，副本大小，PG數字的OSD的列表，他們的狀態（例如，up，in）。要查看一個OSD映射，執行以下命令

# ceph osd dump

3.PG映射：

包含PG版本，其時間戳記，最後OSD映射時代，完整的比率，如PG ID，每一個配置組集，代理設置，在PG的狀態（例如 active + clean）和每一個池數據使用統計數據。

4.CRUSH映射

包含存儲設備，故障域層次結構（例如，設備，主機，機架，行，空間等），並遍歷層次結構存儲數據時的規則的列表。要查看CRUSH映射，執行命令： getcrushmap –o {filename}，而後經過執行crushtool -D {comp-crushmap-filename} -O {decomp-crushmap-filename}反編譯。你能夠查看在文本編輯器或反編譯的映射或使用命令cat查看。

5.MDS映射

包含了現有的MDS映射從它建立至最後一次修改的時期。它還包含池用於存儲元數據，元數據服務器的列表，以及元數據服務器中。要查看MDS映射，執行以下命令

# ceph mds dump

每一個映射保持一個重複歷史關於其運行狀態的變化。Ceph的監視器保持集羣的主副本映射，包括集羣成員的狀態，變化，和Ceph的存儲集羣的總體健康。

上圖左側的幾個概念說明以下：

1. File —— 此處的file就是用戶須要存儲或者訪問的文件。對於一個基於Ceph開發的對象存儲應用而言，這個file也就對應於應用中的「對象」，也就是用戶直接操做的「對象」。

2. Ojbect —— 此處的object是RADOS所看到的「對象」。Object與上面提到的file的區別是，object的最大size由RADOS限定（一般爲2MB或4MB），以便實現底層存儲的組織管理。所以，當上層應用向RADOS存入size很大的file時，須要將file切分紅統一大小的一系列object（最後一個的大小能夠不一樣）進行存儲。爲避免混淆，在本文中將盡可能避免使用中文的「對象」這一名詞，而直接使用file或object進行說明。

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數量的設置牽扯到數據分佈的均勻性問題。關於這一點，下文還將有所展開。

4. OSD —— 即object storage device，前文已經詳細介紹，此處再也不展開。惟一須要說明的是，OSD的數量事實上也關係到系統的數據分佈均勻性，所以其數量不該太少。在實踐當中，至少也應該是數十上百個的量級纔有助於Ceph系統的設計發揮其應有的優點。

基於上述定義，即可以對尋址流程進行解釋了。具體而言， Ceph中的尋址至少要經歷如下三次映射：

File -> Object映射：

ino（File的元數據，File的惟一id）

ono（File切分產生的某個object的序號）

oid（object id： ino + ono）

此次映射的目的是，將用戶要操做的file，映射爲RADOS可以處理的object。其映射十分簡單，本質上就是按照object的最大size對file進行切分，至關於RAID中的條帶化過程。這種切分的好處有二：一是讓大小不限的file變成最大size一致、能夠被RADOS高效管理的object；二是讓對單一file實施的串行處理變爲對多個object實施的並行化處理。

每個切分後產生的object將得到惟一的oid，即object id。其產生方式也是線性映射，極其簡單。圖中，ino是待操做file的元數據，能夠簡單理解爲該file的惟一id。ono則是由該file切分產生的某個object的序號。而oid就是將這個序號簡單連綴在該file id以後獲得的。舉例而言，若是一個id爲filename的file被切分紅了三個object，則其object序號依次爲0、1和2，而最終獲得的oid就依次爲filename0、filename1和filename2。

這裏隱含的問題是，ino的惟一性必須獲得保證，不然後續映射沒法正確進行。

Object -> PG映射：

hash（oid）&mask -> pgid

mask = PG總數m（m爲2的整數冪）- 1

Ceph指定一個靜態hash函數計算oid的值，將oid映射成一個近似均勻分佈的僞隨機值，而後和mask按位相與，獲得pgid。

首先是使用Ceph系統指定的一個靜態哈希函數計算oid的哈希值，將oid映射成爲一個近似均勻分佈的僞隨機值。而後，將這個僞隨機值和mask按位相與，獲得最終的PG序號（pgid）。根據RADOS的設計，給定PG的總數爲m（m應該爲2的整數冪），則mask的值爲m-1。所以，哈希值計算和按位與操做的總體結果事實上是從全部m個PG中近似均勻地隨機選擇一個。基於這一機制，當有大量object和大量PG時，RADOS可以保證object和PG之間的近似均勻映射。又由於object是由file切分而來，大部分object的size相同，於是，這一映射最終保證了，各個PG中存儲的object的總數據量近似均勻。

從介紹不難看出，這裏反覆強調了「大量」。只有當object和PG的數量較多時，這種僞隨機關係的近似均勻性才能成立，Ceph的數據存儲均勻性纔有保證。爲保證「大量」的成立，一方面，object的最大size應該被合理配置，以使得一樣數量的file可以被切分紅更多的object；另外一方面，Ceph也推薦PG總數應該爲OSD總數的數百倍，以保證有足夠數量的PG可供映射。

PG -> OSD映射：

採用CRUSH算法，將pgid代入其中，而後獲得一組共n個OSD（n由部署配置文件決定，通常3個）

第三次映射就是將做爲object的邏輯組織單元的PG映射到數據的實際存儲單元OSD。如圖所示，RADOS採用一個名爲CRUSH的算法，將pgid代入其中，而後獲得一組共n個OSD。這n個OSD即共同負責存儲和維護一個PG中的全部object。前已述及，n的數值能夠根據實際應用中對於可靠性的需求而配置，在生產環境下一般爲3。具體到每一個OSD，則由其上運行的OSD deamon負責執行映射到本地的object在本地文件系統中的存儲、訪問、元數據維護等操做。

和「object -> PG」映射中採用的哈希算法不一樣，這個CRUSH算法的結果不是絕對不變的，而是受到其餘因素的影響。其影響因素主要有二：

1、是當前系統狀態，也就是上文邏輯結構中曾經說起的cluster map。當系統中的OSD狀態、數量發生變化時，cluster map可能發生變化，而這種變化將會影響到PG與OSD之間的映射。

2、是存儲策略配置。這裏的策略主要與安全相關。利用策略配置，系統管理員能夠指定承載同一個PG的3個OSD分別位於數據中心的不一樣服務器乃至機架上，從而進一步改善存儲的可靠性。

所以，只有在系統狀態（cluster map）和存儲策略都不發生變化的時候，PG和OSD之間的映射關係纔是固定不變的。在實際使用當中，策略一經配置一般不會改變。而系統狀態的改變或者是因爲設備損壞，或者是由於存儲集羣規模擴大。好在Ceph自己提供了對於這種變化的自動化支持，於是，即使PG與OSD之間的映射關係發生了變化，也並不會對應用形成困擾。事實上，Ceph正是須要有目的的利用這種動態映射關係。正是利用了CRUSH的動態特性，Ceph能夠將一個PG根據須要動態遷移到不一樣的OSD組合上，從而自動化地實現高可靠性、數據分佈re-blancing等特性。

之因此在這次映射中使用CRUSH算法，而不是其餘哈希算法，緣由之一正是CRUSH具備上述可配置特性，能夠根據管理員的配置參數決定OSD的物理位置映射策略；另外一方面是由於CRUSH具備特殊的「穩定性」，也即，當系統中加入新的OSD，致使系統規模增大時，大部分PG與OSD之間的映射關係不會發生改變，只有少部分PG的映射關係會發生變化並引起數據遷移。這種可配置性和穩定性都不是普通哈希算法所能提供的。所以，CRUSH算法的設計也是Ceph的核心內容之一。

Ceph經過三次映射，完成了從file到object、PG和OSD整個映射過程。通觀整個過程，能夠看到，這裏沒有任何的全局性查表操做需求。至於惟一的全局性數據結構cluster map，在後文中將加以介紹。能夠在這裏指明的是，cluster map的維護和操做都是輕量級的，不會對系統的可擴展性、性能等因素形成不良影響。

集羣的維護：

若干個mintor共同負責ceph集羣中全部osd狀態的發現與記錄，並共同造成cluster map的master版本，而後擴散至全體osd和client。Osd使用cluster map進行數據維護，而client使用cluster map進行數據尋址。

在集羣中，各個monitor的功能整體上是同樣的，其相互間的關係能夠被簡單理解爲主從備份關係。所以，在下面的討論中不對各個monitor加以區分。

monitor並不主動輪詢各個OSD的當前狀態。正相反，OSD須要向monitor上報狀態信息。常見的上報有兩種狀況：一是新的OSD被加入集羣，二是某個OSD發現自身或者其餘OSD發生異常。在收到這些上報信息後，monitor將更新cluster map信息並加以擴散。

Cluster map實際內容：

一、Epoch版本號。Cluster map的epoch是一個單調遞增序列。Epoch越大，則cluster map版本越新。所以，持有不一樣版本cluster map的OSD或client能夠簡單地經過比較epoch決定應該聽從誰手中的版本。而monitor手中一定有epoch最大、版本最新的cluster map。當任意兩方在通訊時發現彼此epoch值不一樣時，將默認先將cluster map同步至高版本一方的狀態，再進行後續操做。

二、各個OSD的網絡地址。

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

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

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

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

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

四、CRUSH算法配置參數。代表了Ceph集羣的物理層級關係（cluster hierarchy），位置映射規則（placement rules）。

Client從Monitors中獲得CRUSH MAP、OSD MAP、CRUSH Ruleset，而後使用CRUSH算法計算出Object所在的OSD set。因此Ceph不須要Name服務器，Client直接和OSD進行通訊。僞代碼以下所示：

  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:]

這種數據映射的優勢是：

把Object分紅組，這下降了須要追蹤和處理metadata的數量(在全局的層面上，咱們不須要追蹤和處理每一個object的metadata和placement，只須要管理PG的metadata就能夠了。PG的數量級遠遠低於object的數量級)。

增長PG的數量能夠均衡每一個OSD的負載，提升並行度。

分隔故障域，提升數據的可靠性。

數據操做流程，強一致性：

當某個client須要向Ceph集羣寫入一個file時，首先須要在本地完成5.1節中所敘述的尋址流程，將file變爲一個object，而後找出存儲該object的一組三個OSD。這三個OSD具備各自不一樣的序號，序號最靠前的那個OSD就是這一組中的Primary OSD，然後兩個則依次是Secondary OSD和Tertiary OSD。

找出三個OSD後，client將直接和Primary OSD通訊，發起寫入操做（步驟1）。Primary OSD收到請求後，分別向Secondary OSD和Tertiary OSD發起寫入操做（步驟2、3）。當Secondary OSD和Tertiary OSD各自完成寫入操做後，將分別向Primary OSD發送確認信息（步驟4、5）。當Primary OSD確信其餘兩個OSD的寫入完成後，則本身也完成數據寫入，並向client確認object寫入操做完成（步驟6）。

之因此採用這樣的寫入流程，本質上是爲了保證寫入過程當中的可靠性，儘量避免形成數據丟失。同時，因爲client只須要向Primary OSD發送數據，所以，在Internet使用場景下的外網帶寬和總體訪問延遲又獲得了必定程度的優化。

高新能：

Client和Server直接通訊，不須要代理和轉發

多個OSD帶來的高併發度。objects是分佈在全部OSD上。

負載均衡。每一個OSD都有權重值(如今以容量爲權重)。

client不須要負責副本的複製(由primary負責),這下降了client的網絡消耗。

高可靠性：

數據多副本。可配置的per-pool副本策略和故障域佈局，支持強一致性。

沒有單點故障。能夠忍受許多種故障場景；防止腦裂；單個組件能夠滾動升級並在線替換。

全部故障的檢測和自動恢復。恢復不須要人工介入，在恢復期間，能夠保持正常的數據訪問。

並行恢復。並行的恢復機制極大的下降了數據恢復時間，提升數據的可靠性。

主機角色分配

192.168.31.80 admin（ceph-deploy，ntp服務器）

192.168.31.84 osd1（mon*1，osd*3）

192.168.31.85 osd2（mon*1，osd*3）

192.168.31.86 osd3（mon*1，osd*3）

安裝配置前準備工做，在admin主機生成密鑰和公鑰並認證其餘節點服務器

~]# ssh-keygen -t rsa -f ~/.ssh/id_rsa -P ''
~]# ssh-copy-id -i /root/.ssh/id_rsa.pub osd1
~]# ssh-copy-id -i /root/.ssh/id_rsa.pub osd2
~]# ssh-copy-id -i /root/.ssh/id_rsa.pub osd3

admin服務器安裝配置：

#安裝配置ntp服務器
~]# cp -f /usr/share/zoneinfo/Asia/Shanghai /etc/localtime  #修改時區
~]# yum install ntp
~]# vim /etc/ntp.conf 
server 127.127.1.0
fudge 127.127.1.0 stratum 8
restrict default nomodify
~]# systemctl start ntpd
#默認的源比較慢，這裏使用阿里的源
~]# wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo（下載阿里雲的base源）
~]# wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo（下載阿里雲的epel源）
~]# sed -i 's/$releasever/7.2.1511/g' /etc/yum.repos.d/CentOS-Base.repo
~]# vim /etc/yum.repos.d/ceph.repo
[ceph]
name=ceph
baseurl=http://download.ceph.com/rpm-hammer/el7/x86_64/
gpgcheck=0
[ceph-noarch]
name=cephnoarch
baseurl=http://download.ceph.com/rpm-hammer/el7/noarch/
gpgcheck=0
~]# yum makecache

#在admin安裝ceph-deploy
~]# yum install ceph-deploy
#在osd1,osd2,osd3等上安裝ceph包
~]# yum install ceph
#在遠程主機上部署一個集羣，並生成配置文件和集羣內部認證密鑰文件
~]# ceph-deploy mon create-initial
#在遠程主機上部署一個ceph監控（mon）
~]# ceph-deploy mon add node3
#添加一個節點到現有的集羣中，添加完成後須要在ceph.conf中添加上對應的節點，並同步
~]# ceph-deploy --overwrite-conf config push node1 node2 node3
#強行將修改的配置文件同步到其餘節點上
~]# ceph-deploy disk list node1 
#查看節點的磁盤狀況
~]# ceph-deploy osd prepare osd1:/dev/sdc1:/dev/sdb1 osd1:/dev/sdd1:/dev/sdb2 osd1:/dev/sde1:/dev/sdb3
#建立三個osd


rbd create block-csdn --size=100
rbd map rbd/block-csdn
rbd unmap /dev/rbd0