簡述
1、架構哲學
所有組件可擴展
不存在單點故障
解決方案是軟件定義，開源可適配
運行於通用硬件之上
儘可能自我管理
2、CRUSH算法
controlled replication under scalable hashing
在後臺計算數據存儲和讀取的位置
基礎設施感知，CRUSH以多副本的方式保存數據，以保證在失效區域中有些組件失效的情況下數據依舊可用
3、塊存儲
數據被以塊的形式存儲在卷裏，卷會被掛接到節點上
rbd協議（ceph塊設備）：
RBD塊被帶狀分佈在多個Ceph對象之上，而這些對象本身又是分佈在整個Ceph存儲集羣中；
RBD支持全內存式緩存，大大提高其性能；
支持最大的image的大小爲16EB，這些image可以被映射成磁盤給物理裸機、虛擬機或其它主機使用
完全支持雲平臺;在openstack中，可通過cinder（塊）和glance（image）組件來使用ceph塊設備，這樣可使用其copy-on-write特性在很短的時間內創建上千個VM
4、文件系統：
CephFS，一個兼容POSIX的文件系統
Ceph文件系統庫（libcephfs）運行在RADOS庫（librados）之上，
要使用CephFS，集羣節點上最少要配置一個Ceph元數據服務器（MDS）
5、對象存儲
Ceph是通過其object gateway，即RADOS gateway（radosgw）提供對象存儲接口。RADOS gateway利用librgw（RADOS gateway library）和librados這些庫，允許應用程序跟Ceph對象存儲建立連接
RADOS gateway提供RESTful接口讓用戶的應用程序存儲數據到Ceph存儲集羣中。RADOS gateway接口是：
• Swift compatibility Swift 兼容: This is an object storage functionality for the OpenStack Swift API
• Swift 兼容: 這是爲OpenStack Swift API提供的對象存儲功能。
• S3 compatibility S3兼容: This is an object storage functionality for the Amazon S3 API
• S3兼容: 這是爲Amazon S3 API提供的對象存儲功能。
• Admin API: This is also known as the management API or native API, which can be used directly in the application to gain access to the storage system for management purposes
• Admin API: 這也被稱爲管理API或者native API，應用程序可以直接使用它來獲取訪問存儲系統的權限以管理存儲系統。
內容整理
RADOS：是ceph存儲集羣的基礎
爲保證數據的一致性，RADOS在集羣節點上執行數據複製、失敗檢測、數據恢復、數據遷移和再平衡
當執行寫操作到ceph集羣，數據會被以對象的形式存儲在ceph OSD （ceph集羣中唯一存儲實際用戶數據的組件）上
一般，一個osd 守護進程對應集羣中的一個物理硬盤
MON：通過與集羣狀態（OSD、MON、PG、CRUSH映射）保持映射，監測整個集羣的健康。
所有集羣節點向mon節點彙報並共享（節點狀態變化的）信息
mon 不存儲實際數據
librados庫: librados API 支持直接接入RADOS，並且可以建自己的接口（接入ceph存儲集羣）
提供一個本地接口接入 ceph存儲集羣、RADOS、其他服務的基礎（RBD、RGW、POSIX）
RBD：提供塊存儲，一個可以映射、格式化、掛載；和服務器的硬盤類似的設備。
RGW：（RADOS gateway），提供RESTful API接口，
MDS：追蹤文件結構，僅爲CephFS存儲元數據
RBD和RADOS gateway 不需要元數據。
cephFS： 提供POSIX-compliant、任何大小的分佈式文件系統。
需要依賴MDS
ceph RADOS
Reliable Autonomic Distributed Object Store
RADOS以對象的方式存儲數據到池中，查看RODOS的池： rados lspools
查看池中對象清單： rados -p medadata ls
查看集羣的利用情況： rados df
RADOS有2個核心組件：OSD 和MON
OSD
ceph集羣中大部分的工作是由 ceph OSD 守護程序完成的
在OSD中，每個對象都有一個主副本和幾個次副本，分散在所有其他osd中
每一個OSD都是一些對象的主OSD，其他對象的次OSD；次OSD受控於主OSD
當一個硬盤失效，ceph OSD 守護程序明智地參考其他 OSD 進行恢復操作；在此期間，包含失效對象的次OSD會被提升爲主OSD，同時生成新的次副本。這些操作對於客戶端是透明的。
ceph OSD 文件系統
ceph osd 由 物理硬盤驅動、Linux 文件系統 和 ceph osd 服務組成
Linux 文件系統支持 XATTRs ，XATTRs 提供內部數據（對象狀態、快照、元數據、ACL等）給ceph OSD 守護程序，有助於數據管理
ceph osd 日誌
在提交數據到後備存儲之前，ceph首先寫數據到一個被稱爲日誌的緩衝區大小的隔離的存儲區
基於這一原理，ceph 寫所有數據都是首先寫到日誌，然後在到後備存儲區（文件系統、物理硬盤）
osd commands
查看單個節點上的 osd 狀態：
service ceph status osd
查看所有節點的osd狀態： (在配置文件ceph.conf中必須有所有osd及其主機名的信息)
service ceph -a status osd
驗證osd ID： ceph osd ls
查看osd 映射和狀態： ceph osd stat
查看osd tree: ceph osd tree
ceph MON
集羣映射包括MON、OSD、PG、CRUSH、MDS 映射等
MON 映射：
一個mon 節點的端對端信息：包括ceph集羣ID，MON主機名和IP地址端口;映射建立時間和最近一次變化信息
查看mon map： `ceph mon dump`
OSD map:
集羣ID，osd map 建立時間和最近一次變化；
和池相關的信息：池的名稱、ID，類型，複製水平，和PG，
osd信息：數量，狀態，權重，last clean interval ，osd主機信息
查看：`ceph osd dump`
PG map:
in-placement group version, 時間戳，最近osd map 時間，full ratio, near full ratio，
追蹤每個PG的 ID，對象數，狀態，狀態戳，up and acting OSD sets,scrub details
查看：`ceph pg dump`
CRUSH map:
集羣存儲設備，失效域層次結構，存儲時針對失效域定義的規則
查看： `ceph osd crush dump`
MDS map：
現在MDS map 時間，映射建立及修改時間，數據和元數據池的ID，集羣MDS數量和狀態
查看： `ceph mds dump`
MON commands
service ceph status mon
ceph mon stat
ceph mon_status
ceph mon dump
librados
librados 是一個本地C庫，提供很多API支持。通過librados庫可以直接與RADOS 集羣直接交互
ceph object gateway
即RADOS gateway；把HTTP請求轉變爲RADOS請求 ，反之亦然
ceph 內在
一個對象典型的有數據和元數據2個組件，它們綁定在一起，並提供一個全局唯一的標識符。
列出ceph集羣所有資源池的名稱： rados lspools
列出metadata池中系統生成的對象名稱： rados -p metadata ls
CRUSH
Controlled Replication Under Scalable Hashing 算法
可以準確算出數據應該被寫入到哪裏或從哪裏讀取。
crush強制集羣中所有磁盤參與；併爲每個osd分配權重，權重越高，表示其物理存儲容量越大。
當新主機或磁盤添加到ceph集羣中，crush開始執行再平衡（rebalancing）操作；建議新加入的osd的權重設爲0，再逐漸增加權重，避免加重集羣再平衡的負載及其性能下降。
crush 管理着pgs在整個集羣內部的再定位
PG
pg 是一組對象的邏輯集合
建議每個osd上放置50-100個pg
pg數計算
PG總數=（osd總數*100）/最大複製數
PG總數=（osd總數*100）/最大複製數/pool數
每個pool 裏面的pg 數一旦配置完成，只能增不能減，
pool 配置 pg 數參考：
少於5個osd：pg_num=128
5和10之間：pg_num=512
10和50之間：pg_num=4096
大於50：pg_num 權衡，計算
osd daemon依賴Extended Attributes (XATTRs)存儲內部對象狀態和元數據
內外網配置
外網：
public network = {public-netwaor/netmask}
內網：
cluster network = {cluster-network/netmask}
如果有內網，osds 的 heartbeat ,object replication ,recovery traffic 將會選擇在內網
ceph客戶端首先會鏈接ceph monitor， 複製一份cluster map 和 CRUSH algorithm ，然後在本地就可以計算每一個object的位置。 ——ceph的高效性，可擴展性
Heartbeat 默認配置
各 OSD 每 6 秒會與其他 OSD 進行心跳檢查,用[osd]下的osd heartbeat interval 可更改此間隔、或運行時更改。如果一個 OSD 20 秒都沒有心跳,集羣就認爲它 down 了,用[osd]下的osd heartbeat grace 可更改寬限期、或者運行時更改。
默認情況下,一個 OSD 必須向監視器報告三次另一個 OSD down 的消息,監視器纔會認爲那個被報告的 OSDdown 了;配置文件裏[mon]段下的 mon osd min down reports 選項(v0.62 之前是 osd min down reports)可更改這個最少 osd down 消息次數,或者運行時設置。默認情況下,只要有一個 OSD 報告另一個 OSD 掛的消息即可,配置文件裏[mon]段下的 mon osd min down reporters 可用來更改必需 OSD 數(v0.62 之前的 osd min downreporters),或者運行時更改。
mon osd down out interval = 1800（在osd停止響應多少秒後把它標記爲down，默認300），手動停止一個osd，等待了1802秒後，ceph開始遷移數據。
如果一 OSD 至少 120 秒沒向監視器報告過,監視器就認爲它 down 了,你可以設置[osd]下的osd mon reportinterval max來更改此報告間隔,或者運行時更改。
OSD 每 30 秒會報告它自己的狀態,在[osd]段下設置osd mon report interval min可更改 OSD 報告間隔,或運行時更改
OSD 默認配置
可以在配置文件裏配置 OSD,但它可以用默認值和最小化配置。最簡 OSD 配置需設置 osd journal size 和osd host,其他幾乎都能用默認值
除了爲對象保存多個副本外,ceph 還靠洗刷歸置組來保證數據完整性。這種洗刷類似對象存儲層的 fsck,對每個歸置組,ceph 生成一個所有對象的目錄,並比對每個主對象及其副本以確保沒有對象丟失或錯配。輕微
洗刷(每天)檢查對象尺寸和屬性,深層洗刷(每週)會讀出數據並用校驗和保證數據完整性。
osd op threads=4
osd disk threads=2
當增加或移除 OSD 時,CRUSH 算法將要求重新均衡集羣,它會把一些歸置組移出或移入多個 OSD 以回到均衡狀態。歸置組和對象的遷移過程會明顯降低集羣運營性能,爲維持運營性能,ceph 用 backfilling 來執行此遷移,它可以使得 ceph 的回填操作優先級低於用戶讀寫請求。（通過優先級來區分讀寫請求，這個做法很好！）
如果某 OSD 崩潰並重生,通常和其他 OSD 不同步,沒有同歸置組內最新版本的對象。這時,OSD 進入恢復模式並且搜索最新數據副本,並更新運行圖。根據 OSD 掛的時間長短,OSD 的對象和歸置組可能明顯過期,另外,如果一個失效域掛了(如一個機櫃),多個 OSD 會同時重生,這樣恢復時間更長、更耗資源。
ceph 擴展屬性用底層文件系統(如果沒有尺寸限制)的 XATTR 存儲爲 inline xattr。
本文出自“he ivy”的博客，轉載請務必保留此出處：http://blog.csdn.net/heivy/article/details/50560684