Ceph是一个开源的、分布式的、提供软件定义的统一的存储解决方案。是一个可大规模扩展、高性能并且无单点故障的分布式存储系统。
Ceph存储集群是由几个不同的软件守护进程组成，每个守护进程负责Ceph的一个独特功能并将值添加到相应的组件中。每个守护进程是彼此独立的。
可靠、自动、分布式对象存储（RADOS）是Ceph存储集群的基础。Ceph中的一切都以对象的形式存储，而RADOS就负责存储这些对象，而不考虑数据类型。RADOS层确保数据一致性和可靠性。对于数据一致性，他执行数据复制、故障检测和恢复，它还包括数据在集群节点间的迁移和再平衡。
数据分布是分布式存储系统的一个重要部分，数据分布至少要考虑以下3种因素
1、故障域隔离。同份数据的不同副本分布在不同的故障域，降低数据损坏的风险
2、负载均衡。数据能够均匀的分布在磁盘容量不等的存储节点，避免部分节点空闲，部分节点超载，从而影响系统性能。
3、控制节点加入离开时引起的数据迁移量。当节点离开时，最有的数据迁移是只有离线节点上的数据迁移到其他节点，而正常工作的节点的数据不会发生迁移。
Ceph总体表现在：集群可靠性、集群扩展性、数据安全性、接口统一性，充分发挥存储本身计算能力和去除所有的中心节点
存储设备具有吞吐量限制，他影响读写性能和可扩展性能，所以存储系统通常都支持条带化以增加存储系统的吞吐量和提升性能。
将条带单元（stripe unit）从阵列的第一个硬盘到最后一个硬盘收集起来，既可以称为条带
数据在阵列中的硬盘上是以条带形式分布的，条带化是指数据在阵列中所有硬盘中的存储过程。文件中的数据被分割成小块的数据段在阵列中的硬盘上顺序存储，这个最小的数据块就叫做条带单元。
决定Ceph条带化数据的3个因素：对象大小、条带宽度、条带总量
对象
一个对象通常包含绑定在一起的数据和元数据，并且用一个全局唯一的标识符标识。这个唯一的标识符确保在整个存储集群中没有其他对象使用相同的对象ID，从而保证对象的唯一性。
Object与PG
Ceph条带化之后，将获取N个带有唯一oid（object 的id）。Object id是进行线性映射生成的，即由file的元数据、Ceph条带化产生的Object的序列号连缀而成。
此时Object需要映射到PG中，包括：
1、由Ceph集群指定的静态Hash函数计算Object的oid，获取到其Hash值
2、将该Hash值与mask进行操作，从而获得PG ID
PG数为M，mask值为M-1
PG与OSD
由PG映射到数据存储的实际单元OSD中，该映射是由CRUSH算法来确定的，将PG ID作为该算法的输入，获得到包含N个OSD集合，集合中第一个OSD被作为主OSD，其他的OSD则依次作为从OSD。OSD集合中的OSD将共同存储和维护该PG下的Object。
CRUSH算法的结果不是绝对不变的，而是受到其他因素影响，主要有两个：
1、当前系统状态。也就是Cluster Map（集群映射）。当系统中的OSD状态、数量发生变化时，Cluster Map可能发生变化，这种变化会影响到PG和OSD之间的映射。
2、存储策略配置。这里的策略主要与安全相关。
因此在Cluster Map和存储策略多不发生变化的时候，PG和OSD之间的映射关系才是固定不变的。一般在实际生产中，策略一经配置通常不会改变。而系统状态的改变因为设备损坏或者是扩大集群规模。Ceph提供了对这种变化的动态支持。即便PG与OSD之间的映射关系发生了变化，并不会对应用造成困扰。正是利用了CRUSH的动态特性，Ceph才可以将一个PG根据需要动态迁移到不同的OSD组合上，从而自动化的实现可靠性、数据分布re-blancing等特性。
之所以用CRUSH算法而不是其他Hash算法
1、CRUSH具有可配置特性，可以根据管理员的配置参数决定OSD的物理位置映射策略。
2、CRUSH具有特殊的“稳定性”，也就是当系统中加入新的OSD导致系统规模增大时，大部分PG与OSD之间的映射关系不会发生改变，只有少部分PG的映射关系会发生变化并引发数据迁移。
PG与Pool
Pool“池”，存储对象的逻辑分区
Ceph Client端从Ceph mon端检索Cluster Map，写入对象到Pool。Pool的副本数目，CRUSH规则和PG数目决定了Ceph将数据存储的位置。
Pool至少需要设定的参数1、对象额所有权/访问权；2、PG数目；3、该pool使用的CRUSH规则；4、对象副本的数目
CRUSH是一种基于伪随机控制数据分布、复制的算法。Ceph是为大规模分布式存储系统（PB级的数据和成百上千台存储设备）而设计的，在大规模的存储系统里，必须考虑数据的平衡分布和负载（提高资源利用率）、最大化系统性能，以及系统的扩展和硬件容错等。
CRUSH关系分析
CRUSH算法是通过存储设备的权重来计算数据对象的分布的。在计算过程中，通过Cluster Map（集群映射）、Data Distribution Policy（数据分布策略）和给出的一个随机数共同决定数据对象的最终位置。
Cluster Map
Cluster Map记录所有可用的存储资源及相互间的空间结构。在Ceph存储里，数据的索引都是通过各种不同的Map来实现的；Map使得Ceph集群存储设备在物理层做了一层防护。
通过设置合理的Map（故障域设置为Host级），可以保证在某一台服务器死机的情况下，有其他副本保留在正常的存储节点上，能够继续提供服务，实现存储的高可用。设置更高级别的故障域级别（如Rack、Row等）能保证整机柜或者同一排机柜在掉电的情况下数据的可用性和完整性。
默认配置，当集群里有组件出现故障时（主要是OSD，也可能是磁盘或者网络等），Ceph会把OSD标记为down，如果在300s内未能恢复，集群就开始进行恢复状态。这个"300s"可以通过'mon osd down out interval'配置选项修改等待时间。PG是Ceph数据管理（包括复制、修复等动作单元）。当客户端把读写请求（对象单元）推送到Ceph时，通过CRUSH提供的Hash算法把对象映射到PG。PG在CRUSH策略的影响下，最终会被映射到OSD上。
CRUSH查找
CRUSH机制工作方式：元数据计算的负载是分布式的并且只在需要时执行。（元数据的计算也被称为CRUSH查找）
CRUSH查找优势：它不依赖系统，Ceph给客户端提供了足够的灵活性来按需执行元数据计算，也就是说，客户端使用自己的系统资源来执行CRUSH查找，从而消除中心查找。
PG归置组
PG是一组对象的逻辑集合，ceph先将object映射成PG，然后从PG映射成OSD。object可以是数据文件的一部分，也可以是journal file，也可以目录文件（包括内嵌的inode节点）。PG是一种间址，PG的数量有限，记录PG跟OSD间的映射关系可行，而记录object到OSD之间的映射因为数量巨大而实际不可行或效率太低。
无论使用哪种存储方式（对象、块、挂载），存储的数据都会被切分成对象（Objects）。Objects size大小可以由管理员调整，通常为2M或4M。每个对象都会有一个唯一的OID，由ino与ono生成，虽然这些名词看上去很复杂，其实相当简单。ino即是文件的File ID，用于在全局唯一标示每一个文件，而ono则是分片的编号。比如：一个文件FileID为A，它被切成了两个对象，一个对象编号0，另一个编号1，那么这两个文件的oid则为A0与A1。Oid的好处是可以唯一标示每个不同的对象，并且存储了对象与文件的从属关系。由于ceph的所有数据都虚拟成了整齐划一的对象，所以在读写时效率都会比较高。
但是对象并不会直接存储进OSD中，因为对象的size很小，在一个大规模的集群中可能有几百到几千万个对象。这么多对象光是遍历寻址，速度都是很缓慢的；并且如果将对象直接通过某种固定映射的哈希算法映射到osd上，当这个osd损坏时，对象无法自动迁移至其他osd上面（因为映射函数不允许）。为了解决这些问题，ceph引入了归置组的概念，即PG。
PG是一个逻辑概念，我们linux系统中可以直接看到对象，但是无法直接看到PG。它在数据寻址时类似于数据库中的索引：每个对象都会固定映射进一个PG中，所以当我们要寻找一个对象时，只需要先找到对象所属的PG，然后遍历这个PG就可以了，无需遍历所有对象。而且在数据迁移时，也是以PG作为基本单位进行迁移，ceph不会直接操作对象。
对象时如何映射进PG的？还记得OID么？首先使用静态hash函数对OID做hash取出特征码，用特征码与PG的数量去模，得到的序号则是PGID。由于这种设计方式，PG的数量多寡直接决定了数据分布的均匀性，所以合理设置的PG数量可以很好的提升CEPH集群的性能并使数据均匀分布。
最后PG会根据管理员设置的副本数量进行复制，然后通过crush算法存储到不同的OSD节点上（其实是把PG中的所有对象存储到节点上），第一个osd节点即为主节点，其余均为从节点。
PGP
PGP是为了实现定位而设置的PG，他的值应该与PG的总数（pg_num）保持一致，对于Ceph的一个池而言，如果增加PG数目（pg_num），你还需要调整pgp_num到同样的值，这样集群才能开始再平衡。参数pg_num定义了PG的数量，这些PG映射到OSD，当任意池的pg_num增加的时候，这个池的每个PG都一分为二，但他们依然保持跟源OSD的映射。直到这个时候，Ceph依然没有开始再平衡，此时，你应该增加该池pgp_num的值，PG才从开始源OSD迁移到其他OSD，正式开始再平衡。
#PGP是PG的逻辑承载体。在Ceph集群中，增加PG数量，PG到OSD的映射关系就会发生变化，但此时存储在PG里的数据并不会发生迁移，只有当PGP的数量也增加时，数据才会正真开始。
#关于PG和PGP的关系，加入把PG比作参加宴会的人，PGP就是椅子，如果人员增加，人的作为排序会发生变化，只有增加椅子时，正真的座位排序才会落实。在Ceph里PG与PGP的数是一致的。
ceph池子pg总数：PG总数=（（OSD总数X100）/最大副本数）/池数
ceph osd pool get pool_name pg_num #获取现有PG值
ceph osd pool get pool_name pgp_num #获取现有PGP值
ceph osd dump | grep size #找到rep size #获取池副本数
ceph osd dump | grep size| wc -l #获取池子数
ceph osd ls #获取ceph osd数
ceph osd pool set pool_name pg_num XXX #修改池子的pg数
ceph osd pool set pool_name pgp_num XXX #修改池子的pgp数
PG状态
creating（创建中）：PG正在被创建。通常当存储池正在被创建或增加一个存储池的PG数目时，PG会呈现这种状态。
down（失效的）：包含PG必须数据的一个副本失效（down）了，因此PG是离线的（down）。
replay（重做）：某OSD崩溃后PG正在等待客户端重新发起操作。
splitting（分割中）：PG正在被分割为多个PG。该状态通常在一个存储池的PG数增加后呈现。比如说，当你的rbd存储池的PG数目从64增加到128后，已有的PG将会被分割，他们的部分对象会被移动到新的PG上。
scrubbing（清理中）：PG正在做不一致性校验。
inconsistent（不一致的）：PG的副本出现不一致，比方说，对象的大小不正确，或者恢复（recovery）结束后某副本出现对象丢失的情形。
peering（对等互联中）：在peering状态下，OSD的PG都处在acting集合中，存储PG副本，并保持PG中的对象和元数据保持一致。在peering操作完成后，存储PG的所有OSD都确认彼此当前的状态。
repair（修复中）：PG正在被检查，被发现的任何不一致都将尽可能的被修复。
active（活动的）：在peering操作完成后，ceph将PG状态置为active。处在active状态下，说明主PG及副本中的数据都处在能提供I/O操作的状态。
clean（清洁的）：处在clean状态下，主OSD和副本OSD已经彼此确认，所有PG都在正确位置，没有发生偏移，而且所有对象都复制好正确的副本数。
degraded[dɪ'greɪdɪd]（降级的）：一旦有OSD处于down状态，ceph将分配到该OSD上的所有PG状态变为degraded状态。在OSD重新处于up状态之后，它将再次执行pee操作使得所有处于degraded状态的PG变 为clean。如果OSD持续处于down状态超过300s后，它的状态将变为out，此时ceph将从副本中恢复所有处于degraded状态的PG以维持复制数。即使PG处于degraded状态，客户端依然可以执行I/O操作。还有一个能使得PG状态变为degraded状态的原因，就是当一个PG内有一个或多个对象变得不可用时。ceph假设对象应该处于该PG中，但实际上它不可以用。在这种情况下，ceph将该PG状态标记为degraded状态并试图从其副本中恢复PG，PG中部分对象的副本数未达到规定数目
recovering[rɪ'kʌvərɪŋ]（恢复中）：当一个OSD处于down状态后，其PG内容将会落后于放置在其他OSD上的副本PG的数据。这样一旦OSD恢复up操作，ceph将会针对这些PG启动恢复操作，使得他们的数据与其他OSD上的PG副本保持一致。
backfilling['bækfɪlɪŋ]（回填中）：一旦一个新的OSD添加到新的集群中，ceph将通过移动其他OSD节点一些PG到这个新的OSD以试图再次平衡数据;这个过程称为backfilling。一旦PG的bcakfilling操作完成，OSD可以参与到客户端的I/O操作中。ceph会在后台平滑的执行backfilling，确保集群不会超载。
backfill-wait（回填-等待）:PG正在等待开始回填操作。
incomplete（不完整的）：PG日志中缺失了一关键时间段的数据。当包含PG所需信息的某OSD失效或者不可用之后，往往会出现这种情况。
remapped（重映射）：每当PG的acting集合有变化，就会触发数据迁移，数据从老的acting集合OSD向新的acting集合OSD转移。根据需要迁移到新的OSD的数量大小，该操作可能需要一些时间。在这段时间内，依旧由老的acting组内的老的主副本OSD为客户端请求提供服务。一旦数据迁移操作完成，ceph使用acting组中新的主副本OSD
stale（陈旧的）：ceph OSD会每隔0.5s向ceph monitor报告其统计结果。任何时候，如果PG acting组的主副本OSD没有成功向monitor报告统计结果，或者其他OSD报告它们的主副本OSD状态为down状态，monitor将考虑这些PG已经处于stale状态。
POOL池子
Pool是ceph存储数据时的逻辑分区，它起到namespace的作用，每个pool包含一定数量的PG，PG里的对象被映射到不同的OSD上，因此pool是分布到整个集群的。用来隔离数据
Ceph池是一个用来存储对象的逻辑分区，Ceph中的每一个池都包含一定数量的PG，进而实现把一定数量的对象映射到集群内部不同的OSD上的目的。因此，每一个池都是交叉分布在集群的所有节点上的，这样就能够提供足够的弹性。我们在调用API存储即使用对象存储时，需要指定对象要存储进哪一个POOL中。除了隔离数据，我们也可以分别对不同的POOL设置不同的优化策略，比如副本数、数据清洗次数、数据块及对象大小等。
Ceph对象存储
Ceph是一个分布式对象存储系统，通过它的对象网关（object gateway），也就是RADOS网关（radosgw）提供对象存储接口。RADOS网关利用librgw（RADOS网关库）和librgw这些库，允许应用程序根ceph对象建立连接。Ceph通过RESTful API提供可访问且最稳定的多租户对象存储解决方案之一。
对象存储不能像文件系统的磁盘那样被操作系统直接访问，相反，它只能通过API在应用层面被访问。Ceph是一个分布式对象存储系统，该系统通过建立在Ceph RADOS层之上的Ceph对象网关（也被称为RADOS网关RGW接口）提供对象存储接口，RGW使用librgw（RADOS网关库）和librados，允许应用程序与Ceph对象存储建立连接。该RGW为应用提供了RESTful S3/Swift兼容的API接口，以在Ceph集群中存储对象格式的数据。Ceph还支持多租户对象存储，通过RESTful API存取。除此之外，RGW还支持Ceph Admin API，他们用于通过原生API调用来管理Ceph存储集群。
librados软件库非常灵活，允许用户应用程序通过C、C++、Java、Python和PHP绑定（bindings）直接访问Ceph存储集群。Ceph对象存储还具有多站点功能，也就是说，提供了灾难恢复解决方案。
要访问Ceph的对象存储系统，也可以绕开RADOS网关层，这样更灵活并且速度更快。librados软件库允许用户的应用程序通过C、C++、java、python、php直接访问ceph对象存储。如下图：
Ceph对象网关
Ceph对象网关，也称作RADOS网关，它是一个代理，可以将HTTP请求转换为RADOS，同时也可以把RADOS请求转换为HTTP请求，从而提供RESTful对象存储，兼容S3和Swift。Ceph对象存储使用Ceph对象网关守护进程（radosgw）和librgw、librados（即Ceph集群）交互。
RADOS特点
1、将文件映射到Object后，利用Cluster Map通过CRUSH计算而不是查找表方式定位文件数据到存储设备中的位置。优化了传统的文件到块和映射和BlockMap管理
2、RADOS充分利用了OSD的只能特点，将部分任务授权给OSD，最大程度地实现可扩展。
RADOS由两部分组成：OSD、Monitor
OSD：由数目可变的大规模OSD组成的集群，负责存储所有地Objects数据。
Monitor：由少量Monitor组成的强耦合、小规模集群，负责管理Cluster Map。Cluster Map是整个RADOS系统的关键数据结构，管理集群中的所有成员、关系和属性等信息以及数据的分发。
Ceph Monitor负责监视整个集群的运行状况，这些信息都是由维护集群成员的守护程序来提供的，如各个节点之间的状态、集群配置信息。Mmonitor Map、OSD Map、PG Map、MDS Map、CURSH Map统称为集群Map。
RADOS与LIBRADOS
LIBRADOS模块是客户端用来访问RADOS对象存储设备的。Ceph存储集群提供了消息传递层协议，用于客户端与Ceph Monitor与OSD交互，LIBRADOS以库形式为Ceph Client提供了这个功能，LIBRADOS就是操作RADOS对象存储接口。所以Ceph客户端可以用LIBRADOS或者LIBRADOS里封装的相同功能和对象存储交互。LIBRBD和LIBCEPHFS就利用了此功能。你可以利用LIBRADOS直接和Ceph交互（如Ceph兼容的应用程序、Ceph接口等）。
librados
librados是一个本地C语言库，通过它允许应用程序直接与RADOS通讯，这样就可以绕过其他接口层与Ceph集群进行交互。librados是RADOS的一个库，他提供了丰富的API支持，这样就允许应用程序直接、并行地访问集群，而没有HTTP开销。应用程序可以扩展他们的本地协议以便通过直接连接librados来访问RADOS。
Ceph OSD
Ceph的OSD由一个已经存在linux文件系统的物理磁盘驱动器和OSD服务组成。
Ceph 的OSD是Ceph存储集群中最重要的一个基础组件，它负责将实际的数据以对象的形式存储在每一个集群节点的物理磁盘驱动器中。Ceph集群中的大部分工作是由OSD守护进程完成的。
Ceph的核心特性（比如可靠性、自平衡、自恢复和一致性）都始于OSD。在磁盘发生故障的时候，Ceph的OSD守护进程会自动与其他的OSD通信，从而开始执行恢复操作。在这期间，存放故障磁盘对象的辅OSD就会被提升为主OSD，同时，在恢复期间会为对象生成新的辅副本，整个过程对于用户是透明的，这保证了Ceph集群的可靠性和一致性。
linux文件系统对于OSD守护进程而言是相当重要的，因为他决定了支持那些扩展属性（XATTR）。这些文件系统扩展属性能够为OSD守护进程提供内部对象的状态、快照、元数据和ACL等信息，这有助于管理数据。OSD在拥有有效Linux分区的物理磁盘驱动器上进行操作。Linux分区可以是Btrfs（B树文件系统）、XFS或ext4。
Btrfs：与使用XFS和ext4文件系统的OSD相比较，使用Btrfs文件系统额OSD能够提供更加的性能。最主要的一个优点是支持写时复制和可写的快照，这对于虚拟机的部署和克隆非常有用。在文件系统中它还支持透明的压缩、普遍的校验和和多设备的统一管理。Btrfs还支持高效的XATTR、对于小文件的合并，还有SSD上所熟知的集成卷管理，并支持在线fsck特性。尽管有如此多特性，Btrfs目前还不具备应用于生产系统条件。
XFS：这是一个可靠、成熟、且非常稳定的文件系统，因此我们推荐在Ceph生产环节用使用。XFS是最常用的文件系统，也是Ceph默认的文件系统。XFS在元数据的扩展性上存在性能问题。XFS也是一种日志文件系统，也就是说，每次客户端发送数据写入Ceph集群时，首先写入日志空间，然后再写入XFS文件系统。这样的两次写入操作增加了开销，从而使得XFS的性能不如Btrfs，Btrfs没有使用日志。
ext4：ext4文件系统也是一种日志文件系统，是一个适合生产环境下Ceph OSD使用的文件系统，它的受欢迎程度不如XFS，性能不如Btrfs。ext4文件系统因为限制了XATTR的存储容量使得其不具备提供足够的XATTR信息的能力，这也是它并不流行的一个选择。
Ceph集群的一次读写操作
两层映射：Object--->PG--->OSD set #每一次映射都是与其他对象无关的，充分体现了CRUSH的独立性（充分分散）和确定性（可确定的存储位置）
客户端首先联系Ceph monitor并获取一个集群map 副本（包含mon map 、osd map、pg map、mds map），集群map 帮助客户获取集群的状态和配置信息。client端从Ceph Monitor获取Cluster Map之后，client将直接与OSD进行I/O操作交互，不在需要Ceph monitor干预（这使得数据读写过程更为迅速）。
使用对象和池名/ID将数据转换为对象，然后将对象和PG（placement groups 归置组）数一起经过散列来生成其在Ceph池中最后存放在哪一个PG，然后计算好的PG经过CRUSH查找来确定存储和获取数据所需的主OSD位置。计算完准确主OSD ID之后，客户端直接联系OSD来存取数据。所有的这些操作都由客户端执行，不会影响集群性能。主OSD所在节点将执行CRUSH查找操作并计算辅助归置组和OSD的位置来实现数据复制，进而实现高可用性。
Ceph任何写入首先是日志（journal），然后是后备存储。journal持续到后备存储同步，每隔5s。默认情况下，10GB是该journal的常用大小，但journal越大越好。Ceph使用journal综合考虑了存储速度和数据的一致性。journal允许Ceph OSD功能很快做小的写操作；一个随机写入首先写入在上一个连续类型的journal，然后刷新到文件系统。这给了文件系统足够的时间来合并写入磁盘。使用SSD盘作为journal盘能获得相对较好的性能（可以有效缓冲突发负载）。如果日志的速度低于备用存储的速度，这对你的集群性能而言将会是一个限制因素。按照建议，在使用额外的SSD来做日志的时候，每个SSD磁盘最多给4或者5个OSD做日志，一旦超过这个数目的OSD的日志盘子同一个SSD磁盘上，这将是几群的性能瓶颈。
同样，如果采用XFS或者ext4文件系统的多个OSD日志在同一个磁盘上，一旦这个盘出现错误，你将失去你的OSD及其数据，这就是Btrfs的优势：如果发生日志错误的OSD盘使用的Btrfs-based文件系统，他将能够回滚到过去，这样只会导致最小的数据丢失或者没有数据丢失。Btrfs是一个写时复制文件系统，也就是说，如果一个块的内容发生了变化，而针对这个块的写是独立进行的，因此能够保留旧的块。对于这样一个场景下的损坏，数据依然可用，因为旧的内容依然可用。
Ceph monitor
Ceph monitor负责监控整个集群健康状态。他们以守护进程的形式存在，这些守护进程通过存储几群的关键信息来维护集群成员状态、对等节点状态，以及集群配置信息。Ceph monitor通过维护整个集群状态的主副本来完成它的任务。集群map包括monitor、OSD、PG、CRUSH、MDS map。所有这些map统称为集群map。
Ceph monitor不为客户端存储和提供数据，相反，它为客户端以及集群内其他节点提供更新集群map的服务。客户和其他集群节点定期与monitor确认自己持有的是否是集群最新map。
monitor map：它维护monitor节点间端到端的信息，其中包括Ceph集群ID、monitor主机名、IP地址及端口号。它还存储着当前map的创建版本和最后一次修改的信息
#检查集群monitor map：ceph mon dump
OSD map：它存储着一些常见的信息，如集群ID、OSD map创建版本和最后一次修改信息，以及与池相关的信息（如池名字、池ID、类型、副本数和归置组）。它还存储着OSD的一些信息，如数目、状态、权重、最近处于clean状态的间隔以及OSD主机等信息。
#获取OSD map：ceph osd dump
PG map：它存储这归置组的版本、时间戳、最新的OSD map版本、容量充满的比例以及容量接近充满的比例等信息。它同时也跟踪每个归置组的ID、对象数、状态时间戳、OSD的up集合、OSD的acting集合，最后还有清洗等信息。
#检查集群PG map：ceph pg dump
CRUSH map：它存储着集群的存储设备信息、故障域层次结构以及在故障域中定义如何存储数据的规则。
#查看CRUSH map：ceph osd crush dump
MDS map：它存储着当前MDS map的版本，map的创建和修改时间，数据和元数据池ID，集群中MDS的数目以及MDS的状态
#查看MDS map：ceph mds dump
查看mon的状态以及mon的选举状态
ceph daemon mon.bj-ceph37 mon_status
ceph quorum_status
