ceph管理商业存储，对象存储的目录

一、ceph分布式存储为啥

Ceph是根据加州大学Santa Cruz分校的Sage Weil的博士论文所设计开发的新一代自由软件分布式文件系统，其设计目标是良好的可扩展性(PB级别以上)、高性能及高可靠性。

Ceph其命名和UCSC（Ceph的诞生地）的吉祥物有关，这个吉祥物是“Sammy”，一个香蕉色的蛞蝓，就是头足类中无壳的软体动物。这些有多触角的头足类动物，是对一个分布式文件系统高度并行的形象比喻。

其设计遵循了三个原则：数据与元数据的分离，动态的分布式的元数据管理，可靠统一的分布式对象存储机制。本文将从Ceph的架构出发，综合性的介绍Ceph分布式文件系统特点及其实现方式。

更多技术细节参考网页链接

二、***ceph***对象存储的目录***文件夹概念

对象存储（OSS）中文件夹的概念仅是一个逻辑概念，在通过API/SDK的方式设置文件夹的时候可以指定object对应的key值包括前面的目录即可实现该功能。例如，定义object的key为abc/1.jpg就会在该bucket下创建一个abc的文件夹，而在文件夹下即会有一个1.jpg的文件。

对象存储（OSS）中的文件夹其实是一个大小为0KB的空文件。因此，用户创建一个key值为1/的object就会定义文件夹1；并且如果用户创建文件abc/1.jpg，系统是不会创建abc/这个文件的，因此在删除abc/1.jpg后将不会再存在abc这个文件夹。

由于对象存储（OSS）采用的是分布式存储的方式，object并不是根据文件夹进行物理存储的。也就是说并不是一个文件夹下的所有的文件都会存储在一起的。在后端存储的过程中不同的文件夹的文件仅仅是key值的前缀不一样。因此这种架构下就会导致无法很方便的统计某个文件夹下的汇总信息，如文件夹大小、文件夹PV数等。而想要遍历某个文件夹下的所有的文件也需要首先通过ListObject接口获取文件夹下的所有文件的key值（这里需要通过prefix指定文件夹），然后再进行操作。

在逻辑上“中国.mp4”将存放到目录“videos”中

三、ceph分布式存储-常见 PG 故障处理

创建一个新集群后，PG的状态一直处于 active， active+ remapped或 active+ degraded状态，而无法达到 active+ clean状态，那很可能是你的配置有问题。

你可能需要检查下集群中有关 Pool、 PG和 CRUSH的配置项，做以适当的调整。

一般来说，你的集群中需要多于 1个 OSD，并且存储池的 size要大于 1副本。

有时候，我们需要搭建一个单节点的 Ceph实验环境。此时，在开始创建 monitor和 OSD之前，你需要把 Ceph配置文件中的 osd crush chooseleaf type选项从默认值 1（表示 host或 node）修改为 0（表示 osd）。这样做是告诉 Ceph允许把数据的不同副本分布到同一 host的 OSDs上。

如果你已经启动了 2个 OSD，它们都处于 up和 in的状态，但 PG仍未达到 active+ clean状态，那可能是给 osd pool default size设置了一个大于 2的值。

如果你想要在 active+ degraded状态（ 2副本）操作你的集群，可以设置 osd pool default min size为 2，这样你就可以对处于 active+ degraded的对象写入数据。然后你还可以把 osd pool default size的值改为 2，这样集群就可以达到 active+ clean状态了。

另外，修改参数 osd pool default size/min_size后，只会对后面新建的 pool起作用。如果想修改已存在的 pool的 size/min_size，可用下面的命令：

注意：你可以在运行时修改参数值。如果是在 Ceph配置文件中进行的修改，你可能需要重启集群。

如果你设置了 osd pool default size的值为 1，那你就仅有对象的单份拷贝。OSD依赖于其他 OSD告诉自己应该保存哪些对象。如果第一个 OSD持有对象的拷贝，并且没有第二份拷贝，那么也就没有第二个 OSD去告诉第一个 OSD它应该保管那份拷贝。对于每一个映射到第一个 OSD上的 PG（参考 ceph pg dump的输出），你可以强制第一个 OSD关注它应该保存的 PGs：

PG达不到 clean状态的另一个可能的原因就是集群的 CRUSH Map有错误，导致 PG不能映射到正确的地方。

有失败发生后，PG会进入“degraded”（降级）或“peering”（连接建立中）状态，这种情况时有发生。通常这些状态意味着正常的失败恢复正在进行。然而，如果一个 PG长时间处于这些状态中的某个，就意味着有更大的问题。因此 monitor在 PG卡（ stuck）在非最优状态时会告警。我们具体检查：

你可以用下列命令显式地列出卡住的 PGs：

卡在 stale状态的 PG通过重启 ceph-osd进程通常可以修复；卡在 inactive状态的 PG通常是互联问题（参见 PG挂了——互联失败）；卡在 unclean状态的 PG通常是由于某些原因阻止了恢复的完成，像未找到的对象（参见未找到的对象）。

在某些情况下， ceph-osd互联进程会遇到问题，阻值 PG达到活跃、可用的状态。例如， ceph health也许显示：

可以查询到 PG为何被标记为 down：

recovery_state段告诉我们互联过程因 ceph-osd进程挂了而被阻塞，本例是 osd.1挂了，启动这个进程应该就可以恢复。

或者，如果 osd.1发生了灾难性的失败（如硬盘损坏），我们可以告诉集群它丢失（ lost）了，让集群尽力完成副本拷贝。

重要：集群不能保证其它数据副本是一致且最新的，就会很危险！

让 Ceph无论如何都继续：

恢复将继续进行。

某几种失败相组合，可能导致 Ceph抱怨有找不到（ unfound）的对象：

这意味着存储集群知道一些对象（或者存在对象的较新副本）存在，却没有找到它们的副本。下例展示了这种情况是如何发生的，一个 PG的数据存储在 ceph-osd 1和 2上：

这时， 1知道这些对象存在，但是活着的 ceph-osd都没有这些副本。这种情况下，读写这些对象的 IO就会被阻塞，集群只能指望 down掉的节点尽早恢复。这样处理是假设比直接给用户返回一个 IO错误要好一些。

首先，你应该确认哪些对象找不到了：

如果在一次查询里列出的对象太多， more这个字段将为 true，你就可以查询更多。

其次，你可以找出哪些 OSD上探测到、或可能包含数据：

本例中，集群知道 osd.1可能有数据，但它挂了（ down）。所有可能的状态有：

有时候集群要花一些时间来查询可能的位置。

还有一种可能性，对象存在于其它位置却未被列出。例如，集群里的一个 ceph-osd停止且被剔出集群，然后集群完全恢复了；后来一系列的失败导致了未找到的对象，它也不会觉得早已死亡的 ceph-osd上仍可能包含这些对象。（这种情况几乎不太可能发生）。

如果所有可能的位置都查询过了但仍有对象丢失，那就得放弃丢失的对象了。这仍可能是罕见的失败组合导致的，集群在写操作恢复后，未能得知写入是否已执行。以下命令把未找到的（ unfound）对象标记为丢失（ lost）。

上述最后一个参数告诉集群应如何处理丢失的对象。

拥有 PG拷贝的 OSD可能会全部失败，这种情况下，那一部分的对象存储不可用， monitor也就不会收到那些 PG的状态更新了。为检测这种情况，monitor会把任何主 OSD失败的 PG标记为 stale（不新鲜），例如：

可以找出哪些 PG是 stale状态，和存储这些归置组的最新 OSD，命令如下：

如果想使 PG 2.5重新上线，例如，上面的输出告诉我们它最后由 osd.0和 osd.2管理，重启这些 ceph-osd将恢复之（可以假定还有其它的很多 PG也会进行恢复）。

如果你的集群有很多节点，但只有其中几个接收数据，检查下存储池里的 PG数量。因为 PG是映射到多个 OSD的，较少的 PG将不能均衡地分布于整个集群。试着创建个新存储池，设置 PG数量是 OSD数量的若干倍。更详细的信息可以参考 Ceph官方文档—— Placement Groups。

如果你的集群已启动，但一些 OSD没起来，导致不能写入数据，确认下运行的 OSD数量满足 PG要求的最低 OSD数。如果不能满足， Ceph就不会允许你写入数据，因为 Ceph不能保证复制能如愿进行。这个最低 OSD个数是由参数 osd pool default min size限定的。

如果收到 active+ clean+ inconsistent这样的状态，很可能是由于在对 PG做擦洗（ scrubbing）时发生了错误。如果是由于磁盘错误导致的不一致，请检查磁盘，如果磁盘有损坏，可能需要将这个磁盘对应的 OSD踢出集群，然后进行更换。生产环境中遇到过不一致的问题，就是由于磁盘坏道导致的。

当集群中出现 PG不一致的问题时，执行 ceph-s命令会出现下面的信息：

1、查找处于 inconsistent状态的问题 PG：

这个有问题的 PG分布在 osd.1、 osd.2和 osd.0上，其中 osd.1是主 OSD。

2、去主 OSD（ osd.1）的日志中查找不一致的具体对象。

从日志中可以知道，是 rbd_data.1349f035c101d9.0000000000000001这个对象的属性 _丢失了，所以在 scrub的过程中产生了 error。

3、执行 ceph pg repair命令修复问题 PG。

4、检查 Ceph集群是否恢复到 HEALTH_OK状态。

osd.1的日志里也提示修复成功：

如果经过前面的步骤，Ceph仍没有达到 HEALTH_OK状态，可以尝试用下面这种方式进行修复。

1、停掉不一致的 object所属的 osd。

2、刷新该 osd的日志。

3、将不一致的 object移除。

4、重新启动该 osd。

5、重新执行修复命令。

6、检查 Ceph集群是否恢复到 HEALTH_OK状态。

有时候，我们在 ceph-s的输出中可以看到如下的告警信息：

这是因为集群 OSD数量较少，测试过程中建立了多个存储池，每个存储池都要建立一些 PGs。而目前 Ceph配置的默认值是每 OSD上最多有 300个 PGs。在测试环境中，为了快速解决这个问题，可以调大集群的关于此选项的告警阀值。方法如下：

在 monitor节点的 ceph.conf配置文件中添加:

然后重启 monitor进程。

或者直接用 tell命令在运行时更改参数的值而不用重启服务：

而另一种情况， too few PGs per OSD（16< min 20）这样的告警信息则往往出现在集群刚刚建立起来，除了默认的 rbd存储池，还没建立自己的存储池，再加上 OSD个数较多，就会出现这个提示信息。这通常不是什么问题，也无需修改配置项，在建立了自己的存储池后，这个告警信息就会消失。