☰

编辑：

tag-icon • tag-icon kubernetes ceph
编辑：

我目前正在尝试在为期 3 天的阵亡将士纪念日周末处理好这个问题 :D

  • Ceph 13.2.4（文件存储）
  • 车 0.9
  • Kubernetes 1.14.1

https://gist.github.com/sfxworks/ce77473a93b96570af319120e74535ec

我的设置是一个 Kubernetes 集群，其中 rook 负责处理 Ceph。使用 13.2.4 时，我遇到了这个问题，其中一个 OSD 总是重新启动。这是最近发生的。节点上没有发生电源故障或任何其他情况。

2019-05-25 01:06:07.192 7fb923359700  3 rocksdb: [/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/huge/release/13.2.4/rpm/el7/BUILD/ceph-13.2.4/src/rocksdb/db/db_impl_compaction_flush.cc:1929] Compaction error: Corruption: block checksum mismatch: expected 862584094, got 1969278739  in /var/lib/rook/osd1/current/omap/002408.sst offset 15647059 size 3855

本要点中还有几个类似的错误消息。唯一的另一个是：

2019-05-25 01:06:07.192 7fb939a4a1c0  0 filestore(/var/lib/rook/osd1) EPERM suggests file(s) in osd data dir not owned by ceph user, or leveldb corruption

我在节点上检查了这一点。所有节点都是 root，其他节点也是。它也是容器化的，删除 pod 让操作员重新创建它没有帮助。

我能找到的唯一能提供帮助的是https://tracker.ceph.com/issues/21303，但这似乎已经是一年前的事情了。我不确定从哪里开始。任何线索或指向一些文档的提示，或者如果你有解决方案，都会很有帮助。我看到了一些适用于 bluestore 的工具，但我不知道它们有多适用，并且考虑到这种情况，我想非常小心。

最糟糕的情况我也有备选方案。愿意在合理范围内尝试。

编辑：

如果只是 OSD，我可以安全地销毁它并让 rook 重新制作它吗? 这是ceph status最近的

sh-4.2# ceph status
  cluster:
    id:     e5a100b0-6abd-4968-8895-300501aa9200
    health: HEALTH_WARN
            Degraded data redundancy: 3407/13644 objects degraded (24.971%), 48 pgs degraded, 48 pgs undersized

  services:
    mon: 3 daemons, quorum c,a,e
    mgr: a(active)
    osd: 3 osds: 2 up, 2 in

  data:
    pools:   1 pools, 100 pgs
    objects: 6.82 k objects, 20 GiB
    usage:   109 GiB used, 792 GiB / 900 GiB avail
    pgs:     3407/13644 objects degraded (24.971%)
             52 active+clean
             48 active+undersized+degraded

  io:
    client:   366 KiB/s wr, 0 op/s rd, 42 op/s wr

答案1

如果它只是一个 OSD，我可以安全地销毁它并让 rook 重新制作它吗？

根据您的ceph status，您有降级的数据，但没有卡住/关闭的数据。因此，是的，您可以关闭第三个 OSD，但请注意，这样做会使您容易受到任何可能导致剩余 OSD 离线的攻击，同时您努力启动第三个替代 OSD。

EPERM

您是否在做一些非常愚蠢的事情，例如在 NFS 上运行此操作？df /var/lib/rook/osd1显示什么，以及 是什么grep /var/lib/rook/osd1 /proc/mounts？

block checksum mismatch

这也符合 NFS 假设，但也可能是由硬件故障、驱动程序故障、文件系统驱动程序故障造成的（诚然，只有非常) 糟糕的 VFS 配置，或者一些其他我现在想不起来的事情。以下是一些猜测：

  • 是否有可能多个守护进程意外地占用同一个数据目录？
  • uptime机器上有什么？
  • 硬件是否遇到过特殊困难（例如超频）？CPU/内存压力测试是否成功完成？
  • 您没有指定 VM 与硬件，但无论如何，您的堆栈的任何级别是否已-o nobarrier在相关的 FS 上设置？

后续行动

@quantomworks 问：

“我不确定你说的“-o nobarrier”是什么意思。

如果 Ceph 在 MD 上运行，您将拥有至少两个文件系统，最多可拥有无限个文件系统。具体来说，您将拥有：

  1. 您在 Ceph 上托管的文件系统。
  2. 托管 OSD 文件本身的文件系统。
  3. （至 ∞）位于上层文件系统之下的文件系统 - 例如，托管通过-o loop其挂载 OSD 的文件的文件系统。

如果没有专用工具，即使你这样做了，你也无法真正保证屏障得到遵守，因为驱动程序、固件和硬件都会撒谎。基本上，I/O 的发生本身就是一个小奇迹。我在这里要求的问题可能最容易通过在grep -i barrier /proc/mounts所有相关机器上解决，而不是真正试图找出哪些 FS 是真正相关的。

无论如何，让 Ceph OSD 变得非常暴躁的更简单方法之一是提供不可靠的写入语义。“屏障”是在写入流中使用的工具，用于确保无论下游批处理如何，都不会发生任何后屏障将永远保存到磁盘前一切前屏障是持久的。一个简单的例子，银行转账：

写入 1：减少 Abby 的账户余额 100 美元 写入 2：增加 Bobby 的账户余额 100 美元

在这种情况下，如果由于一些先前的写入批处理或磁头在磁性介质上的定位或太阳耀斑，写入 2 先发生，然后机器断电，小鲍比就得到了一些“免费”的钱。因此，在法律部门的坚持下，我们在写入 1 和 2 之间插入了一个屏障请求，从而保证虽然我们可能会在断电时稍微回溯一点时间，但我们永远不会损失一分钱。（当然，如果我们生活在一个像数据库一样的事务一致的世界中，艾比的损失也会得到补偿，但屏障是这种世界首先构建的方式之一。）

Ceph 利用屏障（以及其他技巧）尝试在非正常关闭的情况下同时提供吞吐量和某种形式的数据一致性。后一点也是我要求您提供的原因uptime；虽然还有其他方法可以反复非正常关闭 OSD（kill -9或oom_killer想到），但一个相当可靠的方法是让一个每小时重新启动一次的薄片盒。

相关内容