rook-ceph osd down问题排查

本文详细描述了一次Rook Ceph集群中OSD 9出现down状态的问题,涉及rocksdb数据损坏的排查过程,包括查看crash日志、确认故障原因、磁盘操作、集群状态恢复等步骤。

rook ceph osd 异常(down)问题排查

初始化问题显现,如下:

[root@rook-ceph-tools-78cdfd976c-dhrlx /]# ceph osd tree
ID   CLASS  WEIGHT    TYPE NAME         STATUS  REWEIGHT  PRI-AFF
 -1         15.00000  root default                               
-11          3.00000      host master1                           
  4    hdd   1.00000          osd.4         up   1.00000  1.00000
  9    hdd   1.00000          osd.9       down         0  1.00000
 14    hdd   1.00000          osd.14        up   1.00000  1.00000

在检查ceph集群状态,发现: 37 daemons have recently crashed

[root@rook-ceph-tools-78cdfd976c-dhrlx osd]# ceph -s
  cluster:
    id:     f65c0ebc-0ace-4181-8061-abc2d1d581e9
    health: HEALTH_WARN
            37 daemons have recently crashed

  services:
    mon: 3 daemons, quorum a,c,g (age 9m)
    mgr: a(active, since 13d)
    mds: 1/1 daemons up, 1 hot standby
    osd: 15 osds: 14 up (since 10m), 14 in (since 2h)

  data:
    volumes: 1/1 healthy
    pools:   4 pools, 97 pgs
    objects: 20.64k objects, 72 GiB
    usage:   216 GiB used, 14 TiB / 14 TiB avail
    pgs:     97 active+clean

  io:
    client:   8.8 KiB/s rd, 1.2 MiB/s wr, 2 op/s rd, 49 op/s wr

判断这里显示的应该是历史故障信息,查看历史crash:

ceph crash ls-new
2022-05-13T01:46:58.600474Z_11da8241-7462-49b5-8ab6-83e96d0dd1d9

查看crash日志

ceph crash info 2022-05-13T01:46:58.600474Z_11da8241-7462-49b5-8ab6-83e96d0dd1d9

2393> 2020-05-13 10:24:55.180 7f5d5677aa80 -1 Falling back to public interface
-1754> 2020-05-13 10:25:07.419 7f5d5677aa80 -1 osd.2 875 log_to_monitors {default=true}
-1425> 2020-05-13 10:25:07.803 7f5d48d7c700 -1 osd.2 875 set_numa_affinity unable to identify public interface 'eth0' numa node: (2) No such file or directory
-2> 2020-05-13 10:25:23.731 7f5d4436d700 -1 rocksdb: submit_common error: Corruption: block checksum mismatch: expected 717694145, got 2263389519  in db/001499.sst offset 43727772 size 3899 code = 2 Rocksdb transaction: 
-1> 2020-05-13 10:25:23.735 7f5d4436d700 -1 /home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/gigantic/release/14.2.9/rpm/el7/BUILD/ceph-14.2.9/src/os/bluestore/BlueStore.cc: In function 'void BlueStore::_kv_sync_thread()' thread 7f5d4436d700 time 2020-05-13 10:25:23.733456
/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos7/DIST/centos7/MACHINE_SIZE/gigantic/release/14.2.9/rpm/el7/BUILD/ceph-14.2.9/src/os/bluestore/BlueStore.cc: 11016: FAILED ceph_assert(r == 0)

 ceph version 14.2.9 (581f22da52345dba46ee232b73b990f06029a2a0) nautilus (stable)
 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x14a) [0x56297aa20f7d]
 2: (()+0x4cb145) [0x56297aa21145]
 3: (BlueStore::_kv_sync_thread()+0x11c3) [0x56297af95233]
 4: (BlueStore::KVSyncThread::entry()+0xd) [0x56297afba3fd]
 5: (()+0x7e65) [0x7f5d537bfe65]
 6: (clone()+0x6d) [0x7f5d5268388d]

     0> 2020-05-13 10:25:23.735 7f5d4436d700 -1 *** Caught signal (Aborted) **
 in thread 7f5d4436d700 thread_name:bstore_kv_sync

 ceph version 
<think>我们正在处理关于Rook Ceph问题,特别是关于`rook-ceph-osd-prepare`pod状态为Completed的含义及后续操作。根据KubernetesPod的生命周期,状态Completed表示该Pod中的容器已成功执行并退出。对于`rook-ceph-osd-prepare`这个Job来说,它负责准备OSD(Object StorageDevice)的配置,包括磁盘的初始化、分区等。当这个Job成功完成(即Pod状态为Completed)时,意味着OSD的准备工作已经完成,接下来应该由`rook-ceph-osd`相关的Deployment或DaemonSet来启动实际的OSD服务。可能的操作:1.检查OSD是否成功启动:完成准备工作后,应该查看`rook-ceph-osd`开头的pod是否处于运行状态(Running)。可以使用以下命令:```bashkubectl -n rook-cephget pods-lapp=rook-ceph-osd```2.如果OSD pod没有启动,需要检查日志:-首先查看`rook-ceph-osd-prepare`的日志,虽然它完成了,但可能包含警告或错误信息(注意:Completed状态仅表示程序退出码为0,但可能有不影响退出的错误):```bashkubectl -n rook-cephlogs <rook-ceph-osd-prepare-pod-name>```-然后检查OSD pod的日志:```bashkubectl-nrook-ceph logs<rook-ceph-osd-pod-name>```3.检查存储配置:确保集群配置(cluster.yaml)中的存储设备(devices)正确,并且节点上有可用的磁盘。4.如果准备阶段完成后OSD未能启动,可能需要检查Ceph集群状态:```bashkubectl-nrook-ceph exec-it<rook-ceph-tools-pod-name> --ceph-s```注意:需要先部署Ceph Toolspod(如果还没有部署,可以通过创建`rook-ceph-tools`的deployment来部署)。5.如果一切正常,Completed状态就是期望的结果,无需额外操作。引用[1]中提到了删除集群配置和升级Rook的操作,但用户的问题是关于`rook-ceph-osd-prepare`状态为Completed的含义,因此我们主要解释这个状态的意义和后续操作。注意:`rook-ceph-osd-prepare`是一个Job,它成功完成后,Pod会处于Completed状态,并且不会再次运行,除非删除该Job并重新创建。因此,用户看到Completed状态是正常的,表示准备工作已经完成。相关问题:1.如何诊断`rook-ceph-osd` pod启动失败的问题?2.如何部署CephTools pod来检查Ceph集群状态?3.RookCephOSD的配置过程是怎样的?</think>### rook-ceph-osd-prepare状态为Completed的含义及操作 在Rook Ceph集群中,`rook-ceph-osd-prepare` Pod状态显示为**Completed**表示该Pod已成功完成其设计任务,具体含义如下: 1. **成功完成OSD初始化** OSD Prepare Pod的核心职责是检测、初始化和配置存储设备(如硬盘、SSD)。当状态变为Completed时,表明: - 已识别集群配置中指定的存储设备(如`cluster.yaml`中的`devices`配置) - 已在存储设备上创建必要的分区和文件系统 - 已生成OSD所需的元数据(如OSD ID、密钥环等) - 已完成Ceph OSD的引导准备流程[^1] 2. **正常生命周期** 该Pod属于Kubernetes **Job**类型(非长期运行服务),其设计目标就是执行一次性初始化任务。成功执行后自动终止是预期行为,无需人工干预。 --- ### 后续操作建议 1. **验证OSD运行状态** 检查实际运行OSDPod是否正常启动: ```bash kubectl -n rook-ceph get pods -l app=rook-ceph-osd ``` 预期应看到`rook-ceph-osd-xxx` Pod处于**Running**状态(如`1/1 Running`) 2. **检查Ceph集群健康** 通过Ceph工具箱验证集群状态: ```bash kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- ceph -s ``` 重点关注输出中的: - `health: HEALTH_OK` - `osd: X osds: X up, X in`(OSD数量应与配置一致) 3. **排查异常场景** 若OSD未正常运行: - 检查OSD Prepare日志:`kubectl -n rook-ceph logs <completed-osd-prepare-pod-name>` - 确认存储设备无冲突:`kubectl -n rook-ceph describe nodes | grep -A10 "Allocated resources"` - 验证`cluster.yaml`设备配置与节点实际磁盘匹配(如`sdb`等) --- ### 典型工作流程示意 ```mermaid graph LR A[创建cluster.yaml] --> B[部署Rook Operator] B --> C[启动osd-prepare Job] C -- 成功完成 --> D[状态变为Completed] D --> E[自动创建OSD Deployment] E --> F[OSD Pod进入Running状态] ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值