ceph osd 磁盘损坏处理

本文详细描述了在Ceph集群环境中,如何从mon节点删除故障的OSD,包括定位问题、清除osd数据、重建LV和PV,以及更换损坏硬盘并重建RAID0的过程。涉及的操作包括cephosd、ceph-volume等工具的使用。

环境:cenot7,ceph luminious,服务器为Proliant DL380 Gen9 安装了 hp ilo4

(一) 从 ceph 删除该 osd

1、登陆 ceph mon 节点,查看坏掉的 osd

2、mon 上执行 out osd.x

ceph osd out osd.x

3、从 crush map 中删除 osd.x,防止它再接受数据

ceph osd crush remove osd.x
ceph auth del osd.x
ceph osd rm osd.x
[root@bakmtr01 ~]# ceph -s
  cluster:
    id:     0e38e7c6-a704-4132-b0e3-76b87f18d8fa
    health: HEALTH_OK
 
  services:
    mon: 3 daemons, quorum bakmtr01,bakmtr02,bakmtr03
    mgr: bakmtr03(active), standbys: bakmtr01, bakmtr02
    osd: 99 osds: 99 up, 99 in
    rgw: 3 daemons active
...

确认已经删除

ceph osd destroy osd.x --yes-i-really-mean-it

这些步骤相当于

ceph osd purge osd.x --yes-i-really-mean-it

4、osd 节点执行 umount /var/lib/ceph/osd/ceph-x

umount /var/lib/ceph/osd/ceph-x

5、查找 osd.x 对应的 device,lv、pv、vg

[root@bakcmp31 ~]# ceph-volume inventory /dev/sdt

====== Device report /dev/sdt ======

     available                 False
     rejected reasons          locked
     path                      /dev/sdt
     scheduler mode            deadline
     rotational                1
     vendor                    HP
     human readable size       1.64 TB
     sas address               
     removable   
### Ceph OSD 启动过程中的潜在风险分析 Ceph 是一种分布式存储系统,在其运行过程中,OSD(Object Storage Daemon)作为核心组件之一负责管理数据的实际存储位置以及执行读写操作。然而,在 OSD 的启动过程中可能存在一些潜在的风险因素,这些风险可能会影响整个集群的稳定性和性能。 #### 1. 数据一致性问题 在 OSD 启动时,可能会遇到数据不一致的情况。例如,当主 OSD 和从 OSD 之间的日志存在差异时,可能导致某些对象的状态无法同步。尽管通过 `GetLog` 步骤可以尝试修复这种不一致[^2],但如果权威日志本身存在问题或者网络延迟较高,仍可能出现部分对象丢失或损坏的现象。 #### 2. 崩溃恢复失败 如果某个 OSD 在之前因异常而崩溃,并且未能成功完成 crash recovery 流程,则在其重新上线后可能会引发一系列连锁反应。具体来说,由于未完全处理完毕的操作记录仍然残留于内存缓冲区中,这增加了与其他节点间产生冲突的概率[^1]。一旦发生此类情况,不仅当前 PG (Placement Group)状态会被标记为 degraded 或者 inactive ,还可能进一步影响到依赖于此 PG 提供服务的应用程序正常工作。 #### 3. 资源竞争与死锁现象 随着大规模部署场景下硬件资源愈发紧张,多个进程同时争夺有限CPU周期、磁盘I/O带宽等情况变得越来越普遍。特别是在初次加载大量历史事务日志期间更是如此——此时不但需要消耗额外时间来解析复杂结构化文件格式(如B+树索引),而且还会占用更多临时空间用于暂存中间结果集。如果不加以适当控制的话很容易造成局部区域内的严重拥塞甚至出现死锁定局面。 #### 4. 配置错误引起的隐患 不当设置参数也可能成为威胁来源之一 。比如使用 ceph-deploy 工具创建新的 BlueStore 类型实例时如果没有指定合适的设备路径选项(--data/--block-db/--block-wal etc.) , 就有可能误将重要业务分区分配给后台数据库引擎当作缓存层用途从而降低整体吞吐量表现;又或者是开启了不必要的调试模式却忘记关闭它进而导致生产环境中持续输出冗长无意义的日志信息浪费宝贵储存容量等问题都属于这一范畴内需要注意防范的对象[^3]. ```bash ceph-deploy osd create --bluestore storage2 \ --data /dev/sdc \ --block-db cache/db-lv-0 \ --block-wal cache/wal-lv-0 ``` 以上命令展示了如何正确配置BlueStore类型的OSD以优化性能并减少潜在风险的例子。 --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值