Ceph基础知识简单介绍-1

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/TZ_GG/article/details/80401239

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设置不同的优化策略，比如副本数、数据清洗次数、数据块及对象大小等。