1. 對象存儲
問：我可以存儲多少數據？
您可以存儲的總數據容量和對象個數不受限制。各個 Amazon S3 對象的大小範圍可以從最小 0 字節到最大 5 TB。可在單個 PUT 中上傳的最大數據元爲 5 GB。對於大於 100 MB 的數據元，客戶應該考慮使用分段上傳功能。
理解這個問題，事實上有助於理解RADOS的本質，因此有必要在此加以分析。粗看起來，librados和RADOS GW的區別在於，librados提供的是本地API，而RADOS GW提供的則是RESTful API，二者的編程模型和實際性能不同。而更進一步說，則和這兩個不同抽象層次的目標應用場景差異有關。換言之，雖然RADOS和S3、Swift同屬分 布式對象存儲系統，但RADOS提供的功能更爲基礎、也更爲豐富。這一點可以通過對比看出。
對象存儲和塊存儲
塊存儲和對象存儲的區別從圖中便可以看出來.
- 塊相當於硬盤,將數據分成固定大小的對象存儲在rados中.
- 對象存儲就是講文件對象不論大小,隨意的放在桶中.具體存儲讓ceph自己解決.存儲和讀取只要知道對象特徵值和桶名即可.
2. CEPH 塊設備
塊是一個字節序列（例如，一個 512 字節的數據塊）。基於塊的存儲接口是最常見的存儲數據方法，它們基於旋轉介質，像硬盤、 CD 、軟盤、甚至傳統的 9 磁道磁帶。無處不在的塊設備接口使虛擬塊設備成爲與 Ceph 這樣的海量存儲系統交互的理想之選。
Ceph 塊設備是精簡配置的、大小可調且將數據條帶化存儲到集羣內的多個 OSD. Ceph 塊設備利用 RADOS 的多種能力，如快照、複製和一致性。 Ceph 的 RADOS 塊設備（ RBD ）使用內核模塊或 librbd 庫與 OSD 交互。
Ceph 塊設備靠無限伸縮性提供了高性能，如向內核模塊、或向 abbr:KVM (kernel virtual machines) （如 Qemu 、 OpenStack 和 CloudStack 等雲計算系統通過 libvirt 和 Qemu 可與 Ceph 塊設備集成）。你可以用同一個集羣同時運行 Ceph RADOS 網關、 Ceph FS 文件系統、和 Ceph 塊設備。
CEPH 塊設備 http://docs.ceph.org.cn/rbd/rbd
3. 錯誤處理
3.1 Scrub 機制
解析Ceph: 數據的端到端正確性和 Scrub 機制
https://www.ustack.com/blog/ceph-internal-scrub/
因爲 Ceph 作爲一個應用層的路徑，它利用了 POSIX 接口進行存儲並支持 Parity Read/Write，這時候如果封裝固定數據塊並且加入校驗數據會導致較嚴重的性能問題，因此 Ceph 在這方面只是引入 Scrub 機制(Read Verify)來保證數據的正確性。
簡單來說，Ceph 的 OSD 會定時啓動 Scrub 線程來掃描部分對象，通過與其他副本進行對比來發現是否一致，如果存在不一致的情況，Ceph 會拋出這個異常交給用戶去解決。
Ceph 的 PG.cc 源文件中的 ASCII 流程描述已經非常形象了，這裏只簡述內容和補充部分信息。
1. OSD 會以 PG 爲粒度觸發 Scrub 流程，觸發的頻率可以通過選項指定，而一個 PG 的 Scrub 啓動都是由該 PG 的 Master 角色所在 OSD 啓動
2. 一個 PG 在普通的環境下會包含幾千個到數十萬個不等的對象，因爲 Scrub 流程需要提取對象的校驗信息然後跟其他副本的校驗信息對比，這期間被校驗對象的數據是不能被修改的。因此一個 PG 的 Scrub 流程每次會啓動小部分的對象校驗，Ceph 會以每個對象名的哈希值的部分作爲提取因子，每次啓動對象校驗會找到符合本次哈希值的對象，然後進行比較。這也是 Ceph 稱其爲 Chunky Scrub 的原因。
3. 在找到待校驗對象集後，發起者需要發出請求來鎖定其他副本的這部分對象集。因爲每個對象的 master 和 replicate 節點在實際寫入到底層存儲引擎的時間會出現一定的差異。這時候，待校驗對象集的發起者會附帶一個版本發送給其他副本，直到這些副本節點與主節點同步到相同版本。
4. 在確定待校驗對象集在不同節點都處於相同版本後，發起者會要求所有節點都開始計算這個對象集的校驗信息並反饋給發起者。
5. 該校驗信息包括每個對象的元信息如大小、擴展屬性的所有鍵和歷史版本信息等等，在 Ceph 中被稱爲 ScrubMap。
6. 發起者會比較多個 ScrubMap並發現不一致的對象，不一致對象會被收集最後發送給 Monitor，最後用戶可以通過 Monitor 瞭解 Scrub 的結果信息
用戶在發現出現不一致的對象後，可以通過 “ceph pg repair [pg_id]” 的方式來啓動修復進程，目前的修復僅僅會將主節點的對象全量複製到副本節點，因此目前要求用戶手工確認主節點的對象是”正確副本”。另外，Ceph 允許 Deep Scrub 模式來全量比較對象信息來期望發現 Ceph 本身或者文件系統問題，這通常會帶來較大的 IO 負擔，因此在實際生產環境中很難達到預期效果。
3.2 卡住的歸置組
有失敗時歸置組會進入“degraded”（降級）或“peering”（連接建立中）狀態，這事時有發生，通常這些狀態意味着正常的失敗恢復正在進行。然而，如果一個歸置組長時間處於某個這些狀態就意味着有更大的問題，因此監視器在歸置組卡 （stuck） 在非最優狀態時會警告。我們具體檢查：
inactive （不活躍）——歸置組長時間無活躍（即它不能提供讀寫服務了）；
unclean （不乾淨）——歸置組長時間不乾淨（例如它未能從前面的失敗完全恢復）；
stale （不新鮮）——歸置組狀態沒有被 ceph-osd 更新，表明存儲這個歸置組的所有節點可能都掛了。
你可以擺出卡住的歸置組：
3.3 未找到的對象
某幾種失敗相組合可能導致 Ceph 抱怨有找不到（ unfound ）的對象：
ceph health detail
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
pg 2.4 is active+degraded, 78 unfound
這意味着存儲集羣知道一些對象（或者存在對象的較新副本）存在，卻沒有找到它們的副本。下例展示了這種情況是如何發生的，一個 PG 的數據存儲在
ceph-osd 1 和 2 上：
1 掛了；
2 獨自處理一些寫動作；
1 起來了；
1 和 2 重新互聯， 1 上面丟失的對象加入隊列準備恢復；
新對象還未拷貝完， 2 掛了。
這時， 1 知道這些對象存在，但是活着的 ceph-osd 都沒有副本，這種情況下，讀寫這些對象的 IO 就會被阻塞，集羣只能指望節點早點恢復。這時我們假設用戶希望先得到一個 IO 錯誤。
首先，你應該確認哪些對象找不到了：
還有一種可能性，對象存在於其它位置卻未被列出，例如，集羣裏的一個 ceph-osd 停止且被剔出，然後完全恢復了；後來的失敗、恢復後仍有未找到的對象，它也不會覺得早已死亡的 ceph-osd 上仍可能包含這些對象。（這種情況幾乎不太可能發生）。
如果所有位置都查詢過了仍有對象丟失，那就得放棄丟失的對象了。這仍可能是罕見的失敗組合導致的，集羣在寫入完成前，未能得知寫入是否已執行。以下命令把未找到的（ unfound ）對象標記爲丟失（ lost ）。
ceph pg 2.5 mark_unfound_lost revert|delete
上述最後一個參數告訴集羣應如何處理丟失的對象。
delete 選項將導致完全刪除它們。
revert 選項（糾刪碼存儲池不可用）會回滾到前一個版本或者（如果它是新對象的話）刪除它。要慎用，它可能迷惑那些期望對象存在的應用程序。
3.4 永久性故障
上面的流程的前提故障 OSD 在 PGLog 保存的最大條目數以內加入集羣都會利用 PGLog 恢復，那麼如果在 N 天之後或者發生了永久故障需要新盤加入集羣時，PGLog 就無法起到恢復數據的作用，這時候就需要 backfill(全量拷貝) 流程介入。backfill 會將所有數據複製到新上線的 PG，這裏的流程跟上述過程基本一致，唯一的差異就是在第三步 Primary PG 發現 PGLog 已經不足以恢復數據時，這時候同樣分爲兩種情況:
故障 OSD 擁有 Primary PG，該 PG 在對比 PGLog 後發現需要全量拷貝數據，那麼毫無疑問 Primary PG 在複製期間已經無法處理請求，它會發送一個特殊請求給 Monitor 告知自己需要全量複製，需要將 Replicate PG 臨時性提升爲 Primary，等到自己完成了複製過程纔會重新接管 Primary 角色
故障 OSD 擁有 Replicate PG，該 PG 的 Primary 角色會發起 backfill 流程向該 PG 複製數據，由於故障 OSD 是 Replicate 角色，因此不影響正常 IO 的處理.
4 ceph對象存儲案例
ceph存儲的真實案例
Ceph對象存儲運維驚魂72小時
5 CEPH分佈式文件系統分析報告
講訴源碼,寫的一般,比較混亂
6 源碼
源碼分析
ceph RGW接口源碼解析–Rados數據操作
http://my.oschina.net/u/2271251/blog/355074
非常好的資料
Ceph代碼閱讀方法
http://mindinjector.com/2015/08/23/how-to-read-ceph-code-1-mental-attitude/
ceph網絡層
解析Ceph: 網絡層的處理
http://www.wzxue.com/ceph-network/
7 OSD code
Ceph OSD軟件設計
http://mindinjector.com/2015/08/27/ceph-osd-code-design/
8Ceph ARM 存儲
WDLab 發佈了基於 SuperMicro 的 ARM 存儲，大約有 500 個節點。
The Converged Microserver He8 is a microcomputer built on the existing production Ultrastar® He8 platform. The host used in the Ceph cluster is a Dual-Core Cortex-A9 ARM Processor running at 1.3 GHz with 1 GB of Memory, soldered directly onto the drive’s PCB (pictured). Options include 2 GB of memory and ECC protection. It contains the ARM NEON coprocessor to help with erasure code computations and XOR and crypto engines.
The drive PCB includes the standard disk controller hardware, as well as an additional ARM SoC running Debian Jessie (and Ceph). The connector passes ethernet instead of SATA.
Cluster from front: 25 1u SuperMicro enclosures
大小4 PB 504 node.
集羣信息:
cluster 4f095735-f4b2-44c7-b318-566fc6f1d47c
health HEALTH_OK
monmap e1: 1 mons at {mon0=192.168.102.249:6789/0}
election epoch 3, quorum 0 mon0
osdmap e276: 504 osds: 504 up, 504 in
flags sortbitwise
pgmap v3799: 114752 pgs, 4 pools, 2677 GB data, 669 kobjects
150 TB used, 3463 TB / 3621 TB avail
114752 active+clean
504 OSD CEPH CLUSTER ON CONVERGED MICROSERVER ETHERNET DRIVES http://ceph.com/community/500-osd-ceph-cluster/
9 Ceph Jewel 版本預覽
新存儲BlueStore,
沒有了寫入傳統文件系統的額外消耗。同時我們也避免了日誌元數據的冗餘存儲佔用
Ceph Jewel 版本預覽 : 即將到來的新存儲BlueStore
http://bbs.ceph.org.cn/article/63
NewStore項目是一種存儲實現。它使用RocksDB存儲Ceph日誌，同時Ceph的真正數據對象存儲在文件系統中。如今有了BlueStore技術，數據對象可以無需任何文件系統的接口而直接存儲在物理塊設備上。
災難恢復
10 NBD
RADOS Block Device (RBD)
RBD 的 NBD 實現
NBD是目前 Linux Kernel 很早的網絡存儲機制，基本可以把它理解爲塊接口的 FUSE，NBD 內核模塊可以爲遠程的網絡存儲卷建立一個本地映射，如 /dev/nbd0，每次 IO 請求到這個設備時都會通過 TCP 發到服務器端來完成。按照 NBD 官方的意見，Linux 3.6 以上版本的 nbd 內核模塊纔會比較穩定(筆者還是很疑惑的，NBD在 kernel 2.5就進去了，過了10年還沒穩定。。。)。而最近 Ubuntu Kylin 團隊實現了 librbd on nbd 的實現，主要出於 rbd kernel module 不太穩定且在其他架構上有嚴重問題，同時又需要在 baremetal 上建立本地塊設備，因此選擇了 nbd 作爲另一個實現方案。目前這個計劃已經合併到社區，在下一個 release 就能看到 rbd-nbd 程序了，使用的方式與之前的 rbd map 掛載類似。
星辰天合 國內ceph做的相當好,貢獻了4%代碼
http://www.xsky.com/
