ceph简介
ceph是一个开源的分布式存储系统。支持对象、块、文件存储。
ceph组件
- Monitors
一个Ceph监控器（ceph-mon）维护集群状态的地图，包括监控器地图、管理器地图、OSD地图、MDS地图和CRUSH地图。这些地图是关键的集群状态，需要Ceph守护进程相互协调。监控器也负责管理守护进程和客户端之间的认证。通常需要至少三个监视器来实现冗余和高可用性。
- Managers
一个Ceph管理器守护进程（ceph-mgr）负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率、当前性能指标和系统负载。Ceph Manager 守护进程还主持基于 python 的模块来管理和暴露 Ceph 集群的信息，包括一个基于 Web 的 Ceph Dashboard 和 REST API。通常需要至少两个管理器来实现高可用性。
- Ceph OSDs
一个对象存储守护者（Ceph OSD，ceph-osd）存储数据，处理数据复制，恢复，再平衡，并通过检查其他Ceph OSD守护者的心跳，为Ceph监控者和管理者提供一些监控信息。通常需要至少三个Ceph OSD来实现冗余和高可用性。
- MDSs
一个Ceph元数据服务器（MDS，ceph-mds）代表Ceph文件系统存储元数据（即，Ceph块设备和Ceph对象存储不使用MDS）。Ceph元数据服务器允许POSIX文件系统用户执行基本的命令（如ls，find等），而不会对Ceph存储集群造成巨大的负担。
ceph架构
这里摘录了官网的一部分基础内容，更多内容可以查看官方文档。
ceph底层使用RADOS存储集群。通过librados封装库提供块存储、对象存储，通过CephFS提供文件存储。
图片来源参考内容中的博客：分布式存储ceph集群搭建实战与官网
Ceph Storage Cluster(rados)
Ceph存储集群是所有Ceph部署的基础。基于RADOS，Ceph存储集群由几种类型的守护程序组成。
- Ceph OSD 守护程序（OSD）将数据作为对象存储在一个存储节点上。
- 一个Ceph监视器（MON）维护集群地图的主副本。
- 一个Ceph Manager经理守护程序
一个Ceph存储集群可能包含成千上万的存储节点。
一个最小的系统至少有一个Ceph Monitor和两个Ceph OSD Daemons用于数据复制。
Ceph文件系统，Ceph对象存储和Ceph块设备从Ceph存储集群中读取数据并写入数据。
Ceph File System(cephfs)
CephFS是一个监控POSIX的文件系统。建立在Ceph的分布式对象存储RADOS之上。
CephFS的文件元数据是单独存储在MDSs上面。
对数据的访问是通过MDS集群来协调的，MDS作为分布式元数据缓存状态的权威，由客户和MDS合作维护。
元数据的突变由每个MDS汇总成一系列有效的写入RADOS上的日志；MDS不在本地存储元数据状态。这种模式允许客户在POSIX文件系统的背景下进行连贯和快速的协作。
Ceph Block Device(rdb)
一个块是一个字节的序列（通常是512）。基于块的存储接口是一种成熟和常见的方式来存储数据的媒体，包括HDD，SSD，CD，软盘，甚至磁带。
块设备接口的普遍性是与包括Ceph在内的大规模数据存储互动的完美选择。
Ceph块设备是瘦的，可调整大小的，并在多个OSD上存储数据条带。
Ceph块设备利用RADOS的功能，包括快照，复制和强一致性。
Ceph 块存储客户端通过内核模块或 librbd 库与 Ceph 集群通信。
Ceph Objcect Gteway(radosgw)
Ceph Object Gateway是一个建立在librados之上的对象存储接口。它提供了一个应用程序和Ceph存储集群之间的RESTful网关。Ceph对象存储支持两个接口。
- S3-compatible: Provides object storage functionality with an interface that is compatible with a large subset of the Amazon S3 RESTful API.
- Swift-compatible: Provides object storage functionality with an interface that is compatible with a large subset of the OpenStack Swift API.
Ceph对象存储使用Ceph对象网关守护程序（radosgw），这是一个HTTP服务器，旨在与Ceph存储集群进行交互。
Ceph Object Gateway提供了与Amazon S3和OpenStack Swift兼容的接口，并且它有自己的用户管理。
Ceph Object Gateway可以在相同的Ceph存储集群中存储数据，其中来自Ceph文件系统客户端和Ceph块设备客户端的数据被存储。
S3 API和Swift API共享一个共同的命名空间，这使得它有可能用一个API将数据写入Ceph存储集群，然后用另一个API检索这些数据。
ceph数据存储过程
Ceph存储集群从Ceph客户端接收数据–无论它是通过Ceph块设备、Ceph对象存储、Ceph文件系统还是你使用librados创建的自定义实现–都被存储为RADOS对象。每个对象都被存储在一个对象存储设备上。Ceph OSD Daemons处理存储驱动器上的读、写和复制操作。在旧的Filestore后端，每个RADOS对象被存储为传统文件系统（通常是XFS）上的一个独立文件。使用新的和默认的BlueStore后端，对象被存储在一个类似于单片机的数据库中。
Ceph OSD Daemons将数据存储为平面命名空间中的对象（例如，没有目录的层次）。一个对象有一个标识符，二进制数据，以及由一组名/值对组成的元数据。语义是完全由Ceph客户端决定的。例如，CephFS使用元数据来存储文件属性，如文件所有者，创建日期，最后修改日期，等等。
Note An object ID is unique across the entire cluster, not just the localfilesystem.
可扩展性和高可用性
在传统的架构中，客户与一个集中的组件（如网关、经纪人、API、门面等）对话，它作为一个复杂子系统的单一入口点。这对性能和可扩展性都造成了限制，同时引入了一个单点故障（即，如果集中式组件崩溃了，整个系统也会崩溃）。
Ceph消除了集中式网关，使客户能够直接与Ceph OSD Daemons互动。Ceph OSD Daemons在其他Ceph Nodes上创建对象副本，以确保数据安全和高可用性。Ceph还使用一个监控器集群来确保高可用性。为了消除集中化，Ceph使用了一种叫做CRUSH的算法。
CRUSH简介
Ceph客户端和Ceph OSD守护程序都使用CRUSH算法来有效地计算对象的位置信息，而不是依赖一个中央查询表。与旧的方法相比，CRUSH提供了一个更好的数据管理机制，并通过干净地将工作分配给集群中的所有客户端和OSD守护程序来实现大规模的扩展。CRUSH使用智能数据复制来确保弹性，这更适合于超大规模的存储。下面的章节提供了关于CRUSH如何工作的额外细节。关于CRUSH的详细讨论，请看CRUSH – 受控的、可扩展的、分散的复制数据的放置。
集群地图
Ceph依赖于Ceph客户端和Ceph OSD Daemons对集群拓扑结构的了解，这包括5个地图，统称为 “集群地图”。
- 监控地图。包含集群的fsid，每个监视器的位置，名称地址和端口。它还指出了当前的年代，地图的创建时间，以及最后一次改变的时间。要查看监控地图，请执行 ceph mon dump。
- OSD地图。包含集群的fsid，地图创建和最后修改的时间，池的列表，副本大小，PG号码，OSD的列表和他们的状态（例如，向上，在）。要查看OSD地图，执行ceph osd dump。
- PG 地图。包含PG版本，它的时间戳，最后的OSD地图纪元，完整的比率，以及每个放置组的细节，如PG ID，Up Set，Acting Set，PG的状态（例如，活动+清洁），和每个池的数据使用统计。
- CRUSH地图。包含存储设备的列表，故障域的层次结构（如设备、主机、机架、行、房间等），以及存储数据时穿越层次结构的规则。要查看CRUSH地图，执行ceph osd getcrushmap -o {filename}；然后，通过执行crushtool -d {comp-crushmap-filename} -o {decomp-crushmap-filename}来反编译它。你可以在文本编辑器中或用cat查看反编译后的地图。
- MDS地图。包含当前的MDS地图纪元，地图的创建时间，以及最后一次改变的时间。它还包含存储元数据的池，元数据服务器的列表，以及哪些元数据服务器已经启动并正在运行。要查看一个MDS地图，执行ceph fs dump。
每个地图都保持着其运行状态变化的迭代历史。Ceph Monitors维护集群地图的主副本，包括集群成员，状态，变化，以及Ceph存储集群的整体健康状况。
高可用性监控器
在Ceph客户端可以读取或写入数据之前，他们必须联系一个Ceph监控器，以获得集群地图的最新副本。一个Ceph存储集群可以用一个单一的监视器来操作，然而，这引入了一个单一的故障点（即，如果监视器坏了，Ceph客户端不能读取或写入数据）。
为了增加可靠性和容错性，Ceph支持一个监视器的集群。在一个监视器集群中，延迟和其他故障会导致一个或多个监视器落后于集群的当前状态。由于这个原因，Ceph必须在各种监视器实例之间就集群的状态达成一致。Ceph 总是使用大多数监视器（例如，1，2：3，3：5，4：6，等等）和 Paxos 算法来建立监视器之间关于集群当前状态的共识。
关于配置监视器的细节，请参见监视器配置参考。
About Pools
Ceph存储系统支持 “池 “的概念，它是存储对象的逻辑分区。
Ceph 客户端从 Ceph 监控器中检索群集地图，并将对象写入池中。池的大小或复制的数量，CRUSH规则和放置组的数量决定了Ceph将如何放置数据。
池子至少设置了以下参数。
- 对对象的所有权/访问权
- 安置组的数量，以及
- 要使用的CRUSH规则。
See Set Pool Values for details.
Mapping PGs to OSDs
每个池子都有若干个安置组。CRUSH动态地将PG映射到OSD。当Ceph客户端存储对象时，CRUSH会将每个对象映射到一个放置组。
将对象映射到放置组，在 Ceph OSD Daemon 和 Ceph Client 之间创建了一层指示。Ceph存储集群必须能够增长（或收缩）和重新平衡它存储对象的动态位置。如果Ceph客户端 “知道 “哪个Ceph OSD Daemon有哪个对象，这将在Ceph客户端和Ceph OSD Daemon之间建立一个紧密的耦合。相反，CRUSH算法将每个对象映射到一个放置组，然后将每个放置组映射到一个或多个Ceph OSD Daemons。这层指示允许Ceph在新的Ceph OSD Daemons和底层OSD设备上线时动态地重新平衡。下图描述了 CRUSH 如何将对象映射到放置组，以及放置组映射到 OSD。
有了集群地图的副本和CRUSH算法，客户端可以准确地计算出在读取或写入一个特定的对象时要使用哪个OSD。
