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提供的功能更为基础、也更为丰富。这一点可以通过对比看出。

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 块设备。

3. 错误处理

3.1 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数据操作

非常好的资料

Ceph代码阅读方法

ceph网络层

解析Ceph: 网络层的处理

7 OSD code

Ceph OSD软件设计

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 

9 Ceph Jewel 版本预览

新存储BlueStore,
没有了写入传统文件系统的额外消耗。同时我们也避免了日志元数据的冗余存储占用

Ceph Jewel 版本预览 : 即将到来的新存储BlueStore
 

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 挂载类似。