CEPH集群MON全部挂掉后恢复方法

当CEPH集群所有MON节点挂掉,尤其是配置文件和元数据有备份时,可通过删除MON服务和数据,清理Docker volume,然后逐个恢复MON节点来恢复集群。在kolla环境下,需注意备份特定目录,如配置文件和元数据存储路径,并在恢复过程中避免已存在volume导致的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

CEPH集群MON全部挂掉后恢复方法


2017/11/14 恩松

本文介绍ceph集群中所有mon服务均无法启动或者说mon节点所在服务器os全部无法启动情况下的恢复方法,当然,这种极端情况出现的概率非常低,这里前提是要做好mon节点的配置文件和元数据备份,不然就没办法恢复了。我的环境是使用kolla部署的,恢复方法也都是基于kolla工具下才有效,如果采用物理机部署,具体操作上会有所区别,但大致的思路和原理是一样的。

备份配置文件及元数据

采用kolla部署,默认的元数据存储路径如下

[root@node01 mon]# cd /var/lib/docker/volumes/ceph_mon/_data/mon/ceph-172.21.196.11/
[root@node01 ceph-172.21.196.11]# ls
keyring  store.db

将该目录完整备份

[root@node01 ~]# cp -r /var/lib/docker/volumes/ceph_mon/_data/  /root/ceph-mon-bak/

另外还有 配置文件,里面保存了key,默认路径如下:

[root@node01 ~]# cd /etc/kolla/ceph-mon/
[root@node01 ceph-mon]# ls
ceph.client.admin.keyring  ceph.client.mon.keyring  ceph.client.radosgw.keyring  ceph.conf  ceph.monmap  config.json

同样,将该目录完整备份

[root@node01 ceph-mon]# cp -r /etc/kolla/ceph-mon /root/ceph-mon-bak/

我这里所有的相关进程都是跑在docker里,删除mon服务和数据之前先看下集群的整体状态

[root@node01 kolla]# docker exec -ti ceph_mon /bin/bash
(ceph-mon)[root@node01 /]# ceph -s
    cluster 84ff3941-2337-40ca-bd76-fb3be71b0fdd
     health HEALTH_OK
     monmap e4: 2 mons at {
  
  172.21.196.11=172.21.196.11:6789/0,172.21.196.12=172.21.196.12:6789/0}
     
Ceph 集群中,NVMe 设备的写入速度突然下降可能由多种因素导致。以下是一些常见的原因及对应的排查方法: ### 1. NVMe SSD 的性能退化 NVMe SSD 在长期使用过程中会经历 **垃圾回收(GC)** 和 **磨损均衡(Wear Leveling)** 等内部机制的影响,这些操作可能会显著降低写入性能[^2]。当设备接近满载时,SSD 控制器需要频繁执行垃圾回收以释放可用块,从而增加了 I/O 延迟。 - **排查方法:** - 使用 `nvme smart-log /dev/nvmeXnY` 检查 SSD 的健康状态和剩余寿命。 - 观察 SSD 写入放大系数(Write Amplification Factor),该值越高表示 GC 负担越重。 - 检查 `/sys/block/nvmeXnY/stat` 中的 I/O 统计信息,查看是否有明显的延迟增加。 ```bash # 查看 NVMe 设备的 SMART 信息 nvme smart-log /dev/nvme0n1 ``` ### 2. Ceph OSD 缓存配置不当 Ceph OSD 进程依赖于日志缓存(Journal 或 WAL/DB 分区)来提升写入性能。如果 NVMe 用作 DB/WAL 分区且未正确配置,则可能导致主数据盘(HDD 或其他 NVMe)出现写入瓶颈。 - **排查方法:** - 检查 `/var/log/ceph/ceph-osd.*.log` 日志文件,查看是否有关于日志或缓存空间不足的警告。 - 使用 `ceph daemon osd.<id> config show` 查看当前 OSD 的缓存设置,如 `osd_op_queue`、`osd_max_write_size` 等参数是否合理。 ```bash # 查看 OSD 配置 ceph daemon osd.0 config show | grep "osd_max_write_size\|osd_op_queue" ``` ### 3. 网络与集群负载影响 Ceph 是一个分布式存储系统,所有写入操作都需要通过网络进行副本同步或纠删码编码。如果集群节点之间的网络带宽不足或存在丢包现象,将直接影响写入性能。 - **排查方法:** - 使用 `sar -n DEV` 或 `nload` 监控网卡流量,确认是否存在网络拥塞。 - 检查 Ceph 状态 `ceph -s` 和 `ceph osd perf`,观察是否有高延迟 OSD。 - 使用 `ceph health detail` 查看是否有降级对象或不一致对象引发的修复流量。 ```bash # 查看 OSD 性能指标 ceph osd perf ``` ### 4. 后台恢复任务占用资源 当有 OSD 故障或磁盘替换后,Ceph 会自动启动 PG 恢复、回填(backfill)等后台任务,这些任务会大量占用 NVMe 的 IO 资源,导致前台写入性能下降。 - **排查方法:** - 使用 `ceph -w` 实时观察集群活动,检查是否有正在进行的恢复任务。 - 查看 `ceph pg dump` 输出,分析是否有处于 `recovering` 或 `backfilling` 状态的 PG。 ```bash # 查看 PG 当前状态 ceph pg dump | grep recovering ``` ### 5. 文件系统与载选项不当 NVMe 设备通常格式化为 XFS 或 EXT4 文件系统,并载到 Ceph OSD 数据目录。若文件系统配置不合理(如禁用 DAX、未启用 nobarrier、noatime 等优化选项),也可能导致性能下降。 - **排查方法:** - 检查 `/etc/fstab` 和 `mount` 命令输出,确认是否启用了合适的载选项。 - 使用 `xfs_info` 或 `tune2fs -l` 检查文件系统的特性是否符合预期。 ```bash # 查看载点的载选项 cat /proc/mounts | grep "/var/lib/ceph/osd" ``` ### 6. 系统调度与内核限制 Linux 内核的 I/O 调度器(如 CFQ、Deadline、None)、队列深度(queue_depth)以及 NUMA 架构设置都会对 NVMe 的性能产生影响。如果未针对高性能 NVMe 设备做调优,可能出现吞吐量受限的情况。 - **排查方法:** - 检查 `/sys/block/nvmeXnY/queue/scheduler` 设置,建议设为 `none`(适用于多队列 NVMe)。 - 查看 `/sys/block/nvmeXnY/device/queue_depth` 是否设置为最大支持值(通常为 128 或更高)。 - 使用 `numactl --hardware` 检查 NUMA 节点绑定情况,确保进程与设备位于同一 NUMA 节点上。 ```bash # 设置调度器为 none echo deadline > /sys/block/nvme0n1/queue/scheduler ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值