Ceph 项目的历史
Ceph是个由红帽绝对主导的开源项目，各个厂商的代码贡献率如下所示：
Ceph 项目起源于 Sage Weil 2003 年在加州大学圣克鲁兹分校攻读博士期间的研究课题（Lustre 环境中的可扩展问题）。Ceph 于 2006 年根据 LGPLv2 发布为开源项目，而后由 DreamHost 进行了进一步开发。2011 年，Inktank 公司成立以资助上游开发，并通过其 Inktank Ceph Enterprise 产品为 Ceph 提供专业支持。Inktank 于 2014 年 4 月成为红帽大家庭的一员，Inktank Ceph Enterprise 也变为红帽 Ceph 存储。
此外，Ceph 也与 Linux 内核、OpenStack 项目、CloudStack 项目、Canonical 分发和 SUSE 分发进行了整合。一些公司已将 Ceph 整合为存储设备产品的中心，如富士通的 CD10000 项目和 SANDisk 的 InfiniFlash。Ceph的发展史如下图所示：
直至 2017 年底，上游 Ceph 项目都采取每年发布两个稳定版本的做法。自“Mimic”发行版起，Ceph 项目将按 9 个月发布计划运作。
直至“Luminous”发行版，上游项目都是开发版和长期稳定 (LTS) 版交替发布。例如，“Kraken”属于开发版，而“Luminous”则属于 LTS 版。在 LTS 版本达到 GA 时，上游项目停止更新开发版。在过去，红帽 都使红帽 Ceph 存储的发行版与上游 Ceph 的 LTS 版一致。
自“Infernalis”稳定发行版起，上游 Ceph 项目已采用了新的版本号编号方案。每一稳定发行版递增主要版本号。如果次要版本为 0，则该版本尚在开发之中。如果是 1，则表示此版本为候选发行版。如果次要版本为 2，则该版本已经稳定，可供普通用户使用。
红帽Ceph与Ceph社区的对一个
红帽Ceph企业版目前最新版本是Ceph4，它对应Ceph社区N版本。
红帽 Ceph 存储与上游 Ceph 的关系类似于红帽 企业 Linux 和 Fedora 的关系。红帽 定期将来自上游项目的最新变化整合到可供企业使用、并具备专业支持的产品中，这一产品具有 SLA 保障、培训和扩展的支持生命周期。对红帽 Ceph 存储的改进也会以开源形式回馈到上游项目，让 Ceph 的未来修订能够受益。
红帽Ceph4和Ceph社区的版本对应：
红帽Ceph3和之前版本和Ceph上游社区的对应版本如下所示：
红帽Ceph的企业级支持如下，我们看到Ceph3最晚将在2023年6月27日停止支持。
红帽Ceph 的设计原则
红帽 Ceph 存储提供一个企业级别的、基于软件的统一存储平台，具有灵活的存储政策，支持作为对象、块和文件存储来访问其存储基础架构。它以 Ceph 的最新稳定版为基础，包含一个存储管理仪表板、一套部署工具，以及享有 SLA 的支持服务。
红帽 Ceph 存储技术基础
Ceph 的设计旨在实现以下目标：
每一组件皆可扩展
无单点故障
基于软件（而非专用设备）并且开源（无供应商锁定）
在现成的硬件上运行
尽可能自动管理，减少用户干预
红帽 Ceph 存储技术创新
Ceph 的一大创新是它在 Ceph 存储集群中存储数据的方式。RADOS（可靠的自主分布式对象存储）系统将数据作为对象存储在逻辑存储池中，并且使用可扩展哈希下的受控复制 (CRUSH) 数据放置算法来自动计算应存储对象的位置。任何客户端都能够使用这种算法来决定对象所处的位置，因此无需与中央查找服务器通信就能找到对象。客户端可以通过直接与存储对象的 Ceph 服务器通信来获取对象。类似地，CRUSH 算法也让集群软件能够自动扩展、重新平衡对象、保护数据并从故障中恢复。
RADOS 的一些关键优点包括：
CRUSH 数据放置算法能够根据基础架构变化而动态调整
利用数据定位快速响应故障
无中央查找服务器
不需要位置元数据
客户端与 Ceph 服务器直接通信
多个客户端并行访问，提高吞吐量
所有存储设备独立并行运行
自动数据保护
红帽Ceph的后端存储组件
RADOS 是 Ceph 存储后端，它以下列守护进程为基础，可以横向扩展来满足所部署架构的要求：
monitor (MON)，维护集群状态的 map，用于帮助其他守护进程互相协调。
对象存储设备 (OSD)，存储数据，并且处理数据复制、恢复和重新平衡。
管理器 (MGR)，通过基于 Web 浏览器的仪表板和 REST API，跟踪运行时指标并公开集群信息。
元数据服务器 (MDS)，存储供 CephFS 使用的元数据（而非对象存储或块存储），让客户端能够高效执行 POSIX 命令。
Ceph monitor
Ceph monitor (MON) 是维护 cluster map 主要副本的守护进程。cluster map 是由六种 map 组成的集合，它们含有 Ceph 集群状态及其配置状态的信息。monitor 为分布式决策提供共识。每一集群事件必须正确处理，相应的 map 得到更新，然后更新被复制到每一 monitor 守护进程。
若要应用更新，monitor 必须就集群状态建立共识。这要求配置的 monitor 中有多数可用且就 map 更新达成共识。
为确保 monitor 就集群状态投票时有绝对多数，集群中必须配置奇数个 monitor。这也意味着，配置的 monitor 中必须有超过半数正常发挥作用，Ceph 存储集群才能运行并可访问。如果有效 monitor 的数量低于这个阈值，整个集群将无法被任何客户端访问。这是保护集群数据的完整性所必需的。
Ceph 对象存储设备
Ceph 对象存储设备 (OSD) 是 Ceph 存储集群的构建块。OSD 将存储设备（如硬盘或其他块设备）连接到 Ceph 存储集群。一台存储服务器可以运行多个 OSD 守护进程，并为集群提供多个 OSD。
OSD 节点详细信息中，每个正方形代表一台向集群提供 OSD 的服务器，每个圆形则代表集群中的一台 Ceph monitor。更近距离地查看其中一台服务器可发现，这台服务器提供四个 OSD，它们由四个磁盘提供支持，每个磁盘都使用文件系统进行了格式化。
OSD 工作方式的总体设计目标是尽可能拉近计算与物理数据的距离，让集群的性能能够达到最高的效率。CRUSH 算法用于将对象存储到 OSD 中（使用 PG，如本节后文中所述）。
对象被自动复制到多个 OSD。一个 OSD 是对象的 PG 的 Primary OSD，Ceph 客户端在读取或写入数据时始终联系操作集合中的Primary OSD。其他 OSD 为次要 OSD，在确保集群故障时的数据弹性方面发挥重要作用。
Primary OSD 的功能：
服务所有 I/O 请求
复制和保护数据
检查数据的一致性
重新平衡数据
恢复数据
次要 OSD 的功能：
行动始终受到Primary OSD 的控制
能够变为Primary OSD
每一 OSD 具有自己的 OSD 日志。OSD 日志与文件系统日志无关，而是用于改进对 OSD 的写操作的性能。
来自 Ceph 客户端的写操作本质上通常是随机的 I/O，由 OSD 守护进程顺序写入到日志中。这可以让主机文件系统有更多时间合并写操作来提高效率，从而改进性能。当涉及的所有 OSD 日志记录了写请求后，每个对 Ceph 集群的写操作被确认到客户端。OSD 然后将操作提交到其后备文件系统。每隔几秒钟，OSD 会停止向日志写入新的请求，以将 OSD 日志的内容应用到后备文件系统。然后，它会修剪日志中的已提交请求，回收日志存储设备上的空间。
当 Ceph OSD 或其存储服务器出现故障时，其日志会在 OSD 重新启动后重演。重演序列在最后一个已同步的操作后开始，因为已同步的日志记录已提交到 OSD 的存储，将会从日志中修剪。
OSD 日志使用 OSD 节点上的原始卷，应在单独的设备上配置；若有可能，应使用 SSD 等快速设备以适合性能导向型和/或写入密集型环境。
Ceph Manager
Ceph 管理器 (MGR) 提供一系列集群统计数据。在较旧版本的 Ceph 中，这些统计数据中大部分是由 monitor 收集和维护的，这导致它们在大型集群部署中出现工作过载。为解决这个问题，集群统计数据的收集现在由一种新的守护进程处理，称为 Ceph 管理器。
如果您的集群中没有管理器，这不会影响客户端 I/O 操作。但是，它会导致试图查询集群统计数据的操作失败。为避免这种情形，红帽 建议您为每个集群至少部署两个 Ceph 管理器，各自在单独的故障realm中运行。
管理器守护进程将集群中收集的所有数据的访问集中到一处，并通过 TCP 端口 7000（默认）
元数据服务器
Ceph 元数据服务器 (MDS) 是提供兼容 POSIX 的共享文件系统元数据管理的服务，它支持目录层次结构和文件元数据，包括所有权、时间戳和模式。MDS 使用 RADOS 而非本地存储来存储元数据，而且不能访问文件内容，因为它仅用于文件访问。因此，MDS 属于 Ceph 组件，而非 RADOS 附件。
MDS 可让 CephFS 与 Ceph 对象存储交互，将索引节点 map 到对象，并在树内记忆数据的存储位置。访问 CephFS 文件系统的客户端首先向 MDS 发出请求，这会提供必要的信息以便从正确的 OSD 获取文件。
红帽Ceph的访问方式
客户端可以通过以下方式访问 Ceph 集群：
Ceph 原生 API (
librados)：Ceph 集群的原生接口。在此原生接口基础上构建的服务接口包括 Ceph 块设备、Ceph 对象网关和 Ceph 文件系统。Ceph 对象网关：兼容 Amazon S3 和 OpenStack Swift 的 RESTful API。Ceph 对象网关也称为 RADOS 网关、RADOSGW 或 RGW。
Ceph 块设备（RBD、
librbd）：这是一种 Python 模块，为 RADOS 对象存储提供类似于块设备的接口。每一 Ceph 块设备指代为 RADOS 块设备 (RBD) 镜像。Ceph 文件系统（CephFS、
libcephfs）：通过类 POSIX 文件系统接口提供对 Ceph 集群的访问。
Ceph 原生 API (librados)
librados 是原生的 C 语言库，可以让应用直接与 RADOS 协作来访问 Ceph 集群存储的对象。也有类似的库适用于 C++、Java、Python、Ruby、Erlang 和 PHP。
librados 用作其他 Ceph 接口的底层。例如，Ceph 块设备和 Ceph 对象网关等服务使用 librados 构建而成。
如果您有意最大化性能，建议您在应用中直接使用 librados。这种方式可以在改进 Ceph 环境中存储性能方面达到最佳的效果。如果您有意简化对 Ceph 存储的访问，您可以改为使用 Ceph 提供的更高级访问方式，如 Ceph 对象网关 (RADOSGW)、RADOS 块设备和 CephFS。
RADOS 块设备
Ceph 块设备（RADOS 块设备或 RBD）通过 RBD 镜像在 Ceph 集群内提供块存储。RBD 镜像构建自分散在集群中不同 OSD 的个体对象。数据可以在集群内的对象之间分条。由于组成 RBD 的对象分发到集群的不同 OSD，对块设备的访问自动并行处理。
RBD 目前提供下列功能：
Ceph 集群中虚拟磁盘的存储
Linux 内核中的挂载支持
QEMU、KVM 和 OpenStack Cinder 的启动支持
Ceph 对象网关（RADOS 网关）
Ceph 对象网关（RADOS 网关、RADOSGW 或 RGW）是使用 librados 构建的对象存储接口。它使用这个库来与 Ceph 集群通信，并且直接写入到 OSD 进程。它通过 RESTful API 为应用提供了网关，并且支持两种接口：Amazon S3 和 OpenStack Swift。
Ceph 对象网关提供扩展支持，它不限制可部署的网关数量，而且支持标准的 HTTP 负载均衡器。它解决的一些用例包括：
镜像存储（例如，SmugMug 和 Tumblr）
备份服务
文件存储和共享（例如，Dropbox）
Ceph 文件系统 (CephFS)
Ceph 文件系统 (CephFS) 是一种并行文件系统，提供可扩展的、单层级结构共享磁盘。与 CephFS 中存储的文件关联的元数据由 Ceph 元数据服务器 (MDS) 的管理。这包括文件的访问、更改和修改时间戳等信息。
池
池是 Ceph 存储集群的逻辑分区，用于将对象存储在共同的名称标签下。每个池分配特定数量的散列 bucket，将对象分组到一起进行存储。这些散列 bucket 称为 PG。
分配给每个池的 PG 数量可以独立配置，以匹配数据的类型以及池所需要的访问权限。PG 的数量在池创建之时配置，可以动态增加，但决不能减少。本课程稍后将对这一操作进行更加深入的说明。
CRUSH 算法用于选择托管池数据的 OSD。每个池分配一条 CRUSH 规则，用于其放置策略。CRUSH 规则决定哪些 OSD 存储分配了该规则的所有池的数据。
必须为每个请求指定池名称，并且为每个 Ceph 用户授权权限，不论是集群中的所有池还是一个或多个具体的池。这些权限可以是读取、写入或执行。
PG
PG 将一系列对象聚合到一个散列 bucket 或组中，并且 map 到一组 OSD。一个对象仅属于一个 PG，但属于同一 PG 的所有对象返回相同的散列结果。
对象根据对象名称的散列，使用 CRUSH 算法 map到其 PG。这种放置策略称为 CRUSH 放置规则。放置规则标识在 CRUSH 拓扑中选定的故障realm，以接收各个副本或纠删代码区块。
当客户端将对象写入到池时，它使用池的 CRUSH 放置规则来确定对象的PG。客户端然后使用其 cluster map 的副本、PG 以及 CRUSH 放置规则来计算对象的副本（或其纠删代码区块）应写入到哪些 OSD 中。
当新的 OSD 可供 Ceph 集群使用时，PG 提供的间接层非常重要。在集群中添加或移除 OSD 时，PG 会自动在正常运作的 OSD 之间重新平衡。
将对象 map 到其关联的 OSD
Ceph 客户端从 monitor 获取 cluster map 的最新副本。这会告知它集群中的所有 MON、OSD 和 MDS。这不会告知它对象的存储位置；客户端必须使用 CRUSH 来计算它需要访问的对象位置。
要为对象计算 PG ID，Ceph 客户端需要对象 ID 以及对象的存储池的名称。客户端得出对象 ID 的散列，再以 PG 数为模计算散列来获取 PG ID。接着，它根据池名称查找池的数字 ID，再将池 ID 作为前缀添加到 PG ID 中。
然后，使用 CRUSH 算法确定哪些 OSD 负责某一个 PG（操作集合）。操作集合中目前就绪的 OSD 位于就绪集合中。就绪集合中的第一个 OSD 是对象 PG 的当前 Primary OSD，就绪集合中的所有其他 OSD 为次要 OSD。
Ceph 客户端然后可以直接与 Primary OSD 交互，来访问对象。
总结：Ceph存储数据的本质
Ceph本质上是一种对象存储。对外提供三种访问方式：
Object：兼容Swift和S3的API
Block：支持精简配置、快照、克隆
File：Posix接口，支持快照
下图是Ceph内部工作机制，这与对外接口无关。也就是说，向Ceph中存放一个文件，无论是来自CephFS，块设备或者对象方式，在内部存放都按照如下的逻辑进行。
下面介绍一个PG的概念：
一个文件，例如16M，向ceph存放文件的时候，会被拆分成4个对象，每个4M。然后PG中的对象再存放到不同的OSD上。
那么有人会问，PG的作用是什么？没有PG,一个文件被拆成4个对象，不是也可以直接存放到OSDs上么?
解释如下：
当我们向ceph集群中存放一个文件，这个对象会被拆成几个对象。对象大小默认4MB。我们通过对象的元数据，我们可以找到这些对象。这些对象被存放到不同的PG中。用这种分组的方式，可以将很多文件的对象分组，在找对象的时候，先找PG，实现间接寻址，从而减少每个对象元数据的数量。或者说，有了PG以后，我们再找文件的对象时，就不用挨着OSD去找了。但PG需要一点CPU和内存的开销。一般一个OSD上PG的数量一般在100左右。
例如下图实验环境，ceph集群有3个OSD，320个PG。
Crush算法
ceph内部存放数据的算法使用Crush。全称是：Controlled Replication Under Scalable Hashing。与传统的数据存放方式不同，在Crush算法下，数据的放置不依赖于元数据服务器。CRUSH只需要一个简洁而层次清晰的设备描述，包括存储集群和副本放置策略。这种方法有两个关键的优点:首先,它是完全分布式的,在这个大系统的中的任何一方都可以独立计算任何对象的位置;第二,当pg和osd确定过后，特定数据的放置位置也就确定了，除非这两者发生变动。
CRUSH算法还可以很好的将数据的不同副本放到不同的故障域中。不同的故障域可以设置成在不同机架的服务器上，最大程度地实现高可用。
副本数设置
设置数据的副本是为了保证高可用，这点每种技术都是一样的。比如vg mirror，ASM mirror，vSAN副本等等。
有人写过CEPH 可靠性的计算方法分析，在文章中，作者举例ceph集群有三个节点，副本数为3的情况下，数据的可靠性理论值为9个9。（http://www.oschina.net/question/12_223909）
Ceph中，副本数量没有限制，但从成本和高可用性综合考虑，生产商副本数设置为3应该是比较合理的。
