Ceph简介与体系架构
Ceph简介
Ceph 独一无二地用统一的系统提供了对象、块、和文件存储功能，它可靠性高、管理简便、并且是自由软件。 Ceph 的强大足以改变互联网公司的 IT 基础架构、和管理海量数据的能力。Ceph 可提供极大的伸缩性——供成千用户访问 PB 乃至 EB 级的数据。 Ceph 节点 以普通硬件和智能守护进程作为支撑点， Ceph 存储集群 组织起了大量节点，它们之间靠相互通讯来复制数据、并动态地重分布数据。
ceph是一种开源的分布式的存储系统 包含以下几种存储类型：
- 块存储（rbd）
- 对象存储(RADOS Gateway)，
- 文件系统（cephfs）
分布式存储优点：
- 高可靠： 既满足存储读取不丢失，还要保证数据长期存储。 在保证部分硬件损坏后依然可以保证数据安
- 高性能： 读写速度快
- 可扩展： 分布式存储的优势就是“分布式”，所谓的“分布式”就是能够将多个物理节点整合在一起形成共享的存储池，节点可以线性扩充，这样可以源源不断的通过扩充节点提升性能和扩大容量，这是传统存储阵列无法做到的
块存储（RBD）：
块是一个字节序列（例如，512字节的数据块）。 基于块的存储接口是使用旋转介质（如硬盘，CD，软盘甚至传统的9轨磁带）存储数据的最常用方法。Ceph块设备是精简配置，可调整大小并存储在Ceph集群中多个OSD条带化的数据。 Ceph块设备利用 RADOS 功能，如快照，复制和一致性。 Ceph的RADOS块设备（RBD）使用内核模块或librados库与OSD进行交互，Ceph的块设备为内核模块或QVM等KVM以及依赖libvirt和QEMU与Ceph块设备集成的OpenStack和CloudStack等基于云的计算系统提供高性能和无限可扩展性。 可以使用同一个集群同时运行Ceph RADOS Gateway，CephFS文件系统和Ceph块设备。
linux系统中，ls /dev/下有很多块设备文件，这些文件就是我们添加硬盘时识别出来的； rbd就是由Ceph集群提供出来的块设备。可以这样理解，sda是通过数据线连接到了真实的硬盘，而rbd是通过网络连接到了Ceph集群中的一块存储区域，往rbd设备文件写入数据，最终会被存储到Ceph集群的这块区域中； 总结：块设备可理解成一块硬盘，用户可以直接使用不含文件系统的块设备，也可以将其格式化成特定的文件系统，由文件系统来组织管理存储空间，从而为用户提供丰富而友好的数据操作支持。
文件系统cephfs
Ceph文件系统（CephFS）是一个符合POSIX标准的文件系统，它使用Ceph集群来存储其数据。 Ceph文件系统使用与Ceph块设备相同的Ceph存储集群系统。
用户可以在块设备上创建xfs文件系统，也可以创建ext4等其他文件系统，Ceph集群实现了自己的文件系统来组织管理集群的存储空间，用户可以直接将Ceph集群的文件系统挂载到用户机上使用，
Ceph有了块设备接口，在块设备上完全可以构建一个文件系统，那么Ceph为什么还需要文件系统接口呢？
主要是因为应用场景的不同，Ceph的块设备具有优异的读写性能，但不能多处挂载同时读写，目前主要用在OpenStack上作为虚拟磁盘，而Ceph的文件系统接口读写性能较块设备接口差，但具有优异的共享性。
对象存储
Ceph对象存储使用Ceph对象网关守护进程（radosgw），它是一个用于与Ceph存储集群交互的HTTP服务器。由于它提供与OpenStack Swift和Amazon S3兼容的接口，因此Ceph对象网关具有自己的用户管理。 Ceph对象网关可以将数据存储在用于存储来自Ceph文件系统客户端或Ceph块设备客户端的数据的相同Ceph存储集群中使用方式就是通过http协议上传下载删除对象（文件即对象）。
Ceph的块设备存储具有优异的存储性能但不具有共享性，而Ceph的文件系统具有共享性然而性能较块设备存储差，为什么不权衡一下存储性能和共享性，整个具有共享性而存储性能好于文件系统存储的存储呢，对象存储就这样出现了。
Ceph核心组件介绍
在ceph集群中，不管你是想要提供对象存储，块设备存储，还是文件系统存储，所有Ceph存储集群部署都是从设置每个Ceph节点，网络和Ceph存储开始 的。 Ceph存储集群至少需要一个Ceph Monitor，Ceph Manager和Ceph OSD（对象存储守护进程）。 运行Ceph Filesystem客户端时也需要Ceph元数据服务器。
- Mnitors：Ceph监视器（ceph-mon）维护集群状态的映射，包括监视器映射，管理器映射，OSD映射和CRUSH映射。这些映射是Ceph守护进程相互协调所需的关键集群状态。监视器还负责管理守护进程(OSD)和客户端(client)之间的身份验证。冗余和高可用性通常至少需要三个监视器。
- Managers：Ceph Manager守护程序（ceph-mgr）负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载。 Ceph Manager守护进程还托管基于python的模块来管理和公开Ceph集群信息，包括基于Web的Ceph Dashboard和REST API。高可用性通常至少需要两名Managers。
- Ceph OSD：Ceph OSD（对象存储守护进程，ceph-osd）存储数据，处理数据复制，恢复，重新平衡，并通过检查其他Ceph OSD守护进程来获取心跳，为Ceph监视器和管理器提供一些监视信息。冗余和高可用性通常至少需要3个Ceph OSD。
- MDS：Ceph元数据服务器（MDS，ceph-mds）代表Ceph文件系统存储元数据（即，Ceph块设备和Ceph对象存储不使用MDS）。 Ceph元数据服务器允许POSIX文件系统用户执行基本命令（如ls，find等），而不会给Ceph存储集群带来巨大负担。
总结：
- Ceph 监视器维护着集群运行图的主副本。一个监视器集群确保了当某个监视器失效时的高可用性。存储集群客户端向 Ceph 监视器索取集群运行图的最新副本。
- Ceph OSD 守护进程检查自身状态、以及其它 OSD 的状态，并报告给监视器们。
- 存储集群的客户端和各个 Ceph OSD 守护进程使用 CRUSH 算法高效地计算数据位置，而不是依赖于一个中心化的查询表。它的高级功能包括：基于
librados的原生存储接口、和多种基于librados的服务接口
高可用监视器
Ceph 客户端读或写数据前必须先连接到某个 Ceph 监视器、获得最新的集群运行图副本。一个 Ceph 存储集群只需要单个监视器就能运行，但它就成了单一故障点（即如果此监视器宕机， Ceph 客户端就不能读写数据了）。
为增强可靠性和容错能力， Ceph 支持监视器集群；在一个监视器集群内，延时以及其它错误会导致一到多个监视器滞后于集群的当前状态，因此， Ceph 的各监视器例程必须就集群的当前状态达成一致。Ceph 总是使用大多数监视器（如： 1 、 2:3 、 3:5 、 4:6 等等）和
Paxos 算法就集群的当前状态达成一致。
关于配置监视器的详情，见监视器配置参考。
osd智能程序支撑超大规模
在很多集群架构中，集群成员的主要目的就是让集中式接口知道它能访问哪些节点，然后此中央接口通过一个两级调度为客户端提供服务，在 PB 到 EB 级系统中这个调度系统必将成为最大的瓶颈。
Ceph 消除了此瓶颈：其 OSD 守护进程和客户端都能感知集群，比如 Ceph 客户端、各 OSD 守护进程都知道集群内其他的 OSD 守护进程，这样 OSD 就能直接和其它 OSD 守护进程和监视器通讯。另外， Ceph 客户端也能直接和 OSD 守护进程交互。
Ceph 客户端、监视器和 OSD 守护进程可以相互直接交互，这意味着 OSD 可以利用本地节点的 CPU 和内存执行那些有可能拖垮中央服务器的任务。这种设计均衡了计算资源，带来几个好处：
-
OSD 直接服务于客户端： 由于任何网络设备都有最大并发连接上限，规模巨大时中央化的系统其物理局限性就暴露了。 Ceph 允许客户端直接和 OSD 节点联系，这在消除单故障点的同时，提升了性能和系统总容量。 Ceph 客户端可按需维护和某 OSD 的会话，而不是一中央服务器。
-
OSD 成员和状态： Ceph OSD 加入集群后会持续报告自己的状态。在底层， OSD 状态为
up或down，反映它是否在运行、能否提供服务。如果一 OSD 状态为down且in，表明 OSD 守护进程可能故障了；如果一 OSD 守护进程没在运行（比如崩溃了），它就不能亲自向监视器报告自己是down的。 Ceph 监视器能周期性地 ping OSD 守护进程，以确保它们在运行，然而它也授权 OSD 进程去确认邻居 OSD 是否down了，并更新集群运行图、报告给监视器。这种机制意味着监视器还是轻量级进程。详情见监控 OSD 和心跳。 -
数据清洗： 作为维护数据一致性和清洁度的一部分， OSD 能清洗归置组内的对象。就是说， Ceph OSD 能比较对象元数据与存储在其他 OSD 上的副本元数据，以捕捉 OSD 缺陷或文件系统错误（每天）。 OSD 也能做深度清洗（每周），即按位比较对象中的数据，以找出轻度清洗时未发现的硬盘坏扇区。关于清洗详细配置见
数据清洗_。 -
复制： 和 Ceph 客户端一样， OSD 也用 CRUSH 算法，但用于计算副本存到哪里（也用于重均衡）。一个典型的写情形是，一客户端用 CRUSH 算法算出对象应存到哪里，并把对象映射到存储池和归置组，然后查找 CRUSH 图来确定此归置组的主 OSD 。
客户端把对象写入目标归置组的主 OSD ，然后这个主 OSD 再用它的 CRUSH 图副本找出用于放对象副本的第二、第三个 OSD ，并把数据复制到适当的归置组所对应的第二、第三 OSD （要多少副本就有多少 OSD ），最终，确认数据成功存储后反馈给客户端。
有了做副本的能力， OSD 守护进程就可以减轻客户端的复制压力，同时保证了数据的高可靠性和安全性。
动态集群管理
在伸缩性和高可用性一节，我们解释了 Ceph 如何用 CRUSH 、集群感知性和智能 OSD 守护进程来扩展和维护高可靠性。 Ceph 的关键设计是自治，自修复、智能的 OSD 守护进程。让我们深入了解下 CRUSH 如何运作，如何动态实现现代云存储基础设施的数据放置、重均衡、错误恢复。
关于存储池
Ceph 存储系统支持“池”概念，它是存储对象的逻辑分区。
Ceph 客户端从监视器获取一张集群运行图，并把对象写入存储池。存储池的 size 或副本数、 CRUSH 规则集和归置组数量决定着 Ceph 如何放置数据。
存储池至少可设置以下参数：
- 对象的所有权/访问权限；
- 归置组数量；以及，
- 使用的 CRUSH 规则集。
详情见调整存储池。
PG 映射到 OSD
每个存储池都有很多归置组， CRUSH 动态的把它们映射到 OSD 。 Ceph 客户端要存对象时， CRUSH 将把各对象映射到某个归置组。
把对象映射到归置组在 OSD 和客户端间创建了一个间接层。由于 Ceph 集群必须能增大或缩小、并动态地重均衡。如果让客户端“知道”哪个 OSD 有哪个对象，就会导致客户端和 OSD 紧耦合；相反， CRUSH 算法把对象映射到归置组、然后再把各归置组映射到一或多个 OSD ，这一间接层可以让 Ceph 在 OSD 守护进程和底层设备上线时动态地重均衡。下列图表描述了 CRUSH 如何将对象映射到归置组、再把归置组映射到 OSD 。
有了集群运行图副本和 CRUSH 算法，客户端就能精确地计算出到哪个 OSD 读、写某特定对象。
参考阅读
论文 RADOS - A Scalable, Reliable Storage Service for Petabyte-scale Storage Clusters