ceph学习记录（官网文档翻译）

ceph学习记录

记录ceph学习过程中，收获的知识点、遇到的问题等。

① RADOS：Reliable, Autonomic Distributed Object Store

RADOS是Ceph存储系统的核心，也称为Ceph存储集群。Ceph的所有优秀特性都是由RADOS提供的，包括分布式对象存储、高可用性、高可靠性、没有单点故障、自我修复以及自我管理等。因此，RADOS层在Ceph存储架构中扮演着举足轻重的角色。Ceph的数据访问方法（如RBD、CephFS、RADOSGW和librados）的所有操作都是在RADOS层之上构建的。

参考链接：
Ceph分布式存储学习指南3.2　Ceph RADOS
ceph架构核心之RADOS
RADOS分布式对象存储原理简介
Ceph-设计思想及结构RADOS

知识总结：
（1） 数据的放置：RADOS采用两层映射关系， 第一层映射将存储对象映射到一个PG(Placement Group)， PG是一组存储对象集合， 是复制和负载均衡的最基本单位。第二层映射是基于CRUSH（Controlled Replication Under Scalabe Hashing)哈希算法映射pg到多个OSD， 这些OSD构成复制关系。
      数据以object的方式存储，首先object映射到PG。如果设置的副本数为3，则起码应该有3个OSD。此时根据PGP（Placement Group for Placement，用于归置PG）的数量N，产生OSD的N种不同组合，每个组合表示PG的一种归置方式。其中，每个组合使用3个OSD。
(2）RADOS的三种Replication方案：Primary-copy：读写操作均在primaryOSD上进行，并行更新replicas；Chain：链式读写，读写分离；Spaly：Primary-copy和Chain的折中方案：并行更新replicas和读写分离。

---

② PG与PGP的区别和理解
个人理解：PG数：m，PGP数：n，副本数：i，因此会有m个PG需要归置，会产生OSD的n种组合方式，即PG有n种归置方式。其中，每种归置方式会选择i个OSD最为一个组合，以保证副本数为i。

参考链接：
Ceph中PG和PGP的区别
【OpenStack存储实践】Ceph PG与PGP的关系
总结：
（1）增加PG操作会引起PG内部对象分裂，分裂的份数是根据新增PG组合重复情况来的（其中的第二列为这个PG当中的对象的数目，第三列为PG所在的OSD）：1.1对象分成了两份[3,6,0]，1.3的对象分成了三份[4,1,2]，1.4的对象没有拆分[3,0,4]。

（2）调整PGP不会引起PG内的对象的分裂，但是会引起PG的分布的变动：

PG是指定存储池存储对象的目录有多少个，PGP是存储池PG的OSD分布组合个数
PG的增加会引起PG内的数据进行分裂，分裂到相同的OSD上新生成的PG当中
PGP的增加会引起部分PG的分布进行变化，但是不会引起PG内对象的变动

---

③ RADOS与LIBRADOS、radosgw

LIBRADOS模块是客户端用来访问RADOS对象存储设备的。Ceph存储集群提供了消息传递层协议，用于客户端与Ceph Monitor与OSD交互，LIBRADOS以库形式为Ceph Client提供了这个功能，LIBRADOS就是操作RADOS对象存储的接口。Ceph客户端可以用LIBRADOS或LIBRADOS里封装的相同功能和对象存储交互，LIBRBD和LIBCEPHFS就利用了此功能。

参考链接：
Ceph分布式存储实2.3　RADOS与LIBRADOS
Ceph-设计思想及结构RADOS
ceph radosgw模块介绍
对象存储介绍和实践-基础篇
对ceph radosgw的一些理解
总结：
（1）RADOS GW(RADOS Gateway)、RBD(Reliable Block Device)和Ceph FS(Ceph File System),起作用时在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口。RADOS GW是一个提供Amazon S3 和Swift 兼容的RESTful API 的gateway,以供相应的对象存储应用开发使用)。RAIDS GW 提供的API抽象层次更高，但功能不如librados强大。因此，开发者应针对自己的需求选择使用。RBD则提供了一个标准的块设备接口，常用于在虚拟化的场景下创建volume。Ceph FS 是一个POSIX兼容的分布式文件系统。目前还处于开发状态。
（2）ceph底层实现其实就是一个对象存储Rados对象存储，并提供了Librados 接口，那么为什么还需要一个RGW 来对外提供对象存储接口？
       Librados和RADOSGW的区别在于，librados提供的是本地API，而RADOSGW提供的则是RESTful API，二者的编程模型和实际性能不同。而更进一步说，则和这两个不同抽象层次的目标应用场景差异有关。而librados API的设计思想则与此完全不同。一方面，librados中没有S3 API中账户、容器bucket这样的高层概念；另一方面，librados API向开发者开放了大量的RADOS状态信息与配置参数，允许开发者对RADOS系统底层的存储对象状态进行监测和控制。故它们一个是面对S3 应用层，一个是面向底层。

---

④ monitor的选举机制

Ceph 客户端读或写数据前必须先连接到某个 Ceph 监视器、获得最新的集群运行图副本。一个 Ceph 存储集群只需要单个监视器就能运行，但它就成了单一故障点（即如果此监视器宕机， Ceph 客户端就不能读写数据了）。为增强可靠性和容错能力， Ceph 支持监视器集群；在一个监视器集群内，延时以及其它错误会导致一到多个监视器滞后于集群的当前状态，因此， Ceph 的各监视器例程必须就集群的当前状态达成一致。Ceph 总是使用大多数监视器（如： 1 、 2:3 、 3:5 、 4:6 等等。Paxos 算法就集群的当前状态达成一致。

参考链接：
Ceph Monitor源码机制分析（三）—— 选举
ceph中monitor节点基本解释与图解
Ceph Monitor源码机制分析（三）—— 选举

⑤ 如何实现伸缩性和高可用性

客户端可以直接与OSD守护进程通信

在传统架构里，客户端与一个中心化的组件通信（如网关、中间件、 API 、前端等等），它作为一个复杂子系统的唯一入口，它引入单故障点的同时，也限制了性能和伸缩性（就是说如果中心化组件挂了，整个系统就挂了）。
Ceph 消除了集中网关，允许客户端直接和 Ceph OSD 守护进程通讯。 Ceph OSD 守护进程自动在其它 Ceph 节点上创建对象副本来确保数据安全和高可用性；为保证高可用性，监视器也实现了集群化。为消除中心节点， Ceph 使用了 CRUSH 算法。

如何实现高可用性认证
为识别用户并防止中间人攻击， Ceph 用 cephx 认证系统来认证用户和守护进程。

Cephx 用共享密钥来认证，即客户端和监视器集群各自都有客户端密钥的副本。这样的认证协议使参与双方不用展现密钥就能相互认证，就是说集群确信用户拥有密钥、而且用户相信集群有密钥的副本。


Ceph 一个主要伸缩功能就是避免了对象存储的中央接口，这就要求 Ceph 客户端能直接和 OSD 交互。 Ceph 通过 cephx 认证系统保护数据，它也认证运行 Ceph 客户端的用户， cephx 协议运行机制类似 Kerberos 。

详情见体系结构的高可用性部分。

Ceph 客户端、监视器和 OSD 守护进程可以相互直接交互，带来的好处

① OSD 直接服务于客户端： 由于任何网络设备都有最大并发连接上限，规模巨大时中央化的系统其物理局限性就暴露了。 Ceph 允许客户端直接和 OSD 节点联系，这在消除单故障点的同时，提升了性能和系统总容量。 Ceph 客户端可按需维护和某 OSD 的会话，而不是一中央服务器。

② OSD 成员和状态： Ceph OSD 加入集群后会持续报告自己的状态。在底层， OSD 状态为 up 或 down ，反映它是否在运行、能否提供服务。如果一 OSD 状态为 down 且 in ，表明 OSD 守护进程可能故障了；如果一 OSD 守护进程没在运行（比如崩溃了），它就不能亲自向监视器报告自己是 down 的。 Ceph 监视器能周期性地 ping OSD 守护进程，以确保它们在运行，然而它也授权 OSD 进程去确认邻居 OSD 是否 down 了，并更新集群运行图、报告给监视器。这种机制意味着监视器还是轻量级进程。

③ 数据清洗： 作为维护数据一致性和清洁度的一部分， OSD 能清洗归置组内的对象。就是说， Ceph OSD 能比较对象元数据与存储在其他 OSD 上的副本元数据，以捕捉 OSD 缺陷或文件系统错误（每天）。 OSD 也能做深度清洗（每周），即按位比较对象中的数据，以找出轻度清洗时未发现的硬盘坏扇区。

④ 复制： 和 Ceph 客户端一样， OSD 也用 CRUSH 算法，但用于计算副本存到哪里（也用于重均衡）。一个典型的写情形是，一客户端用 CRUSH 算法算出对象应存到哪里，并把对象映射到存储池和归置组，然后查找 CRUSH 图来确定此归置组的主 OSD 。客户端把对象写入目标归置组的主 OSD ，然后这个主 OSD 再用它的 CRUSH 图副本找出用于放对象副本的第二、第三个 OSD ，并把数据复制到适当的归置组所对应的第二、第三 OSD （要多少副本就有多少 OSD ），最终，确认数据成功存储后反馈给客户端。

详情见体系结构的高可用性部分。

---

⑤ 如何计算PG ID
客户端只需输入对象 ID 和存储池，此事简单： Ceph 把数据存在某存储池（如 liverpool ）中。当客户端想要存命名对象（如 john 、 paul 、 george 、 ringo 等等）时，它用对象名，一个哈希值、 存储池中的归置组数、存储池名计算归置组。 Ceph 按下列步骤计算 PG ID ：
       （1）客户端输入存储池 ID 和对象 ID （如 pool=”liverpool” 和 object-id=”john” ）；
       （2）CRUSH 拿到对象 ID 并哈希它；
       （3）CRUSH 用 PG 数（如 58 ）对哈希值取模，这就是PG ID ；
       （4）CRUSH 根据存储池名取得存储池 ID （如liverpool = 4 ）；
       （5）CRUSH 把存储池 ID 加到PG ID（如 4.58 ）之前。
计算对象位置远快于查询定位。

---

⑥ 纠删编码
纠删码存储池把各对象存储为 K+M 个数据块，其中有 K 个数据块和 M 个编码块。此存储池的尺寸为 K+M ，这样各块被存储到位于 acting set 中的 OSD ，块的位置也作为对象属性保存下来了。比如一纠删码存储池创建时分配了五个 OSD （ K+M = 5 ）并容忍其中两个丢失（ M = 2 ）。

读出和写入编码块

当包含 ABCDEFGHI 的对象 NYAN 被写入存储池时，纠删编码函数把内容分割为三个数据块，只是简单地切割为三份：第一份包含 ABC 、第二份是 DEF 、最后是 GHI ，若内容长度不是 K 的倍数则需填充；此函数还会创建两个编码块：第四个是 YXY 、第五个是 GQC ，各块分别存入 acting set 中的 OSD 内。这些块存储到相同名字（ NYAN ）的对象、但是位于不同的 OSD 上；分块顺序也必须保留，被存储为对象的一个属性（ shard_t ）追加到名字后面。包含 ABC 的块 1 存储在 OSD5 上、包含 YXY 的块 4 存储在 OSD3 上。—>说明：在ceph中，对象是分块存储的。在同一个对象副本的多个OSD上，对象内容是按分块顺序索引。

被中断的完全写

完全写：净载荷将会完全取代此对象，而非部分覆盖。在写的过程中，不是首先就清除V1版本，而是等各块已经写完毕，更改日志的 last_complete 指针就会从 1,1 改为指向 1,2 ，才会清除V1版本的块内容

参考链接：
体系结构的纠删码部分。
Erasure Code developer notes

---

⑦ 缓存分级

对于后端存储层上的部分热点数据，缓存层能向 Ceph 客户端提供更好的 IO 性能。缓存分层包含由相对高速、昂贵的存储设备（如固态硬盘）创建的存储池，并配置为 缓存层；以及一个后端存储池，可以用纠删码编码的或者相对低速、便宜的设备，作为经济存储层。 Ceph 对象管理器会决定往哪里放置对象，分层代理决定何时把缓存层的对象刷回后端存储层。所以缓存层和后端存储层对 Ceph 客户端来说是完全透明的。

缓存层代理自动处理缓存层和后端存储之间的数据迁移，两种场景：

回写模式： 管理员把缓存层配置为 writeback 模式时， Ceph 客户端们会把数据写入缓存层、并收到缓存层发来的 ACK ；写入缓存层的数据会被迁移到存储层、然后从缓存层刷掉。直观地看，缓存层位于后端存储层的“前面”，当 Ceph 客户端要读取的数据位于存储层时，缓存层代理会把这些数据迁移到缓存层，然后再发往 Ceph 客户端。从此， Ceph 客户端将与缓存层进行 I/O 操作，直到数据不再被读写。此模式对于易变数据来说较理想（如照片/视频编辑、事务数据等）。

---

只读模式： 管理员把缓存层配置为 readonly 模式时， Ceph 直接把数据写入后端。读取时， Ceph 把相应对象从后端复制到缓存层，根据已定义策略、脏对象会被缓存层踢出。此模式适合不变数据（如社交网络上展示的图片/视频、 DNA 数据、 X-Ray 照片等），因为从缓存层读出的数据可能包含过期数据，即一致性较差。对易变数据不要用 readonly 模式。

参考链接：
体系结构的缓存分级。
分级缓存

---

⑧ 数据条带化

存储设备都有吞吐量限制，它会影响性能和伸缩性，所以存储系统一般都支持条带化（把连续的信息分片存储于多个设备）以增加吞吐量和性能。数据条带化最常见于 RAID 中， RAID 中最接近 Ceph 条带化方式的是 RAID 0 、或者条带卷， Ceph 的条带化提供了像 RAID 0 一样的吞吐量、像 N 路 RAID 镜像一样的可靠性、和更快的恢复。

Ceph 提供了三种类型的客户端：块设备、文件系统和对象存储。 Ceph 客户端把展现给用户的数据格式（一块设备映像、 REST 风格对象、 CephFS 文件系统目录）转换为可存储于 Ceph 存储集群的对象。在 Ceph 存储集群内存储的那些对象是没条带化的。 Ceph 对象存储、 Ceph 块设备、和 Ceph 文件系统把他们的数据条带化到 Ceph 存储集群内的多个对象，客户端通过 librados 直接写入 Ceph 存储集群前必须先自己条带化（和并行 I/O ）才能享受这些优势。

总结： 一个数据由于大小问题，可能需要存储到不同的object上。采取数据条带化，并且与普通的条带化不同：普通的条带化，是 Ceph 客户端把条带单元写入 Ceph 存储的对象，直到对象容量达到上限，才会再创建另一个对象存储未完的数据。
       客户端数据条带化到一个对象集，它包含 4 个对象，其中，第一个条带单元是 object 0 的 stripe unit 0 、第四个条带是 object 3 的 stripe unit 3 ，写完第四个条带，客户端要确认对象集是否满了。如果对象集没满，客户端再从第一个对象起写入条带（下图中的 object 0 ）；如果对象集满了，客户端就得创建新对象集，然后从新对象集中的第一个对象起开始写入第一个条带（ stripe unit 16 ）。
       Ceph 客户端把数据等分为条带单元并映射到对象后，用 CRUSH 算法把对象映射到归置组、归置组映射到 OSD ，然后才能以文件形式存储到硬盘上。

参考链接：
体系结构的数据条带化

---

⑨ CEPH 客户端

Ceph 客户端包括数种服务接口，有：
       块设备： Ceph 块设备（也叫 RBD ）服务提供了大小可调、精炼、支持快照和克隆的块设备。为提供高性能， Ceph 把块设备条带化到整个集群。 Ceph 同时支持内核对象（ KO ） 和 QEMU 管理程序直接使用librbd ——避免了内核对象在虚拟系统上的开销。
       对象存储： Ceph 对象存储（也叫 RGW ）服务提供了 RESTful 风格_的 API ，它与 Amazon S3 和 OpenStack Swift 兼容。
       文件系统： Ceph 文件系统（ CephFS ）服务提供了兼容 POSIX 的文件系统，可以直接 mount 或挂载为用户空间文件系统（ FUSE ）。

**总结：**① 精简的、可快照的 Ceph 块设备对虚拟化和云计算很有吸引力，精简的 Ceph 块设备搭配 Qemu 和libvirt 来支持 OpenStack 和 CloudStack 。
       ② Ceph 文件系统服务包含随 Ceph 存储集群部署的元数据服务器（ MDS ）。 MDS 的作用是把所有文件系统元数据（目录、文件所有者、访问模式等等）永久存储在相当可靠的元数据服务器中内存中。 MDS （名为 ceph-mds 的守护进程）存在的原因是，简单的文件系统操作像列出目录（ ls ）、或进入目录（ cd ）这些操作会不必要的扰动OSD。所以把元数据从数据里分出来意味着 Ceph 文件系统能提供高性能服务，又能减轻存储集群负载。ceph的MDS是对metadata的缓存，metadata最终持久化存储在OSD中。当某个文件被访问时，MDS从OSD中获取metadata进行缓存。

这是cephfs元数据的内存缓存，为了加快元数据的访问，里面有元数据的cache，也有类似journal一样保持数据 一致性的日志系统。ceph-mds core dump了，并不会引起数据丢失，他仅仅是个缓存，数据已经持久化保存在osd上。重启mds的时候会通过replay的方式从osd上加载之前缓存的元数据。
参考链接：cephfs的数据与元数据组织形式(cephfs探索二)

参考链接：
体系结构的CEPH 客户端