ceph 日誌01

標籤：

1. Object Storage Service

問：我可以儲存多少資料？

您可以儲存的總資料容量和對象個數不受限制。各個 Amazon S3 對象的大小範圍可以從最小 0 位元組到最大 5 TB。可在單個 PUT 中上傳的最大資料元為 5 GB。對於大於 100 MB 的資料元，客戶應該考慮使用分段上傳功能。

理解這個問題，事實上有助於理解RADOS的本質，因此有必要在此加以分析。粗看起來，librados和RADOS GW的區別在於，librados提供的是本地API，而RADOS GW提供的則是RESTful API，二者的編程模型和實際效能不同。而更進一步說，則和這兩個不同抽象層次的目標應用情境差異有關。換言之，雖然RADOS和S3、Swift同屬分 布式Object Storage Service系統，但RADOS提供的功能更為基礎、也更為豐富。這一點可以通過對比看出。

Object Storage Service和Block Storage

Block Storage和Object Storage Service的區別便可以看出來.

• 塊相當於硬碟,將資料分成固定大小的Object Storage Service在rados中.
• Object Storage Service就是講檔案對象不論大小,隨意的放在桶中.具體儲存讓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 detailHEALTH_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 cephObject Storage Service案例

ceph儲存的真實案例

CephObject Storage Service營運驚魂72小時

cephObject Storage Service營運驚魂72小時

5 CEPHDistributed File System分析報告

講訴源碼,寫的一般,比較混亂

http://www.docin.com/p-152954423.html

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的真正資料Object Storage Service在檔案系統中。如今有了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/

ceph 日誌01