news 2026/4/16 10:48:16

ceph运维运维

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
ceph运维运维

Ceph运维手册

  1. Ceph 模块说明 1
    1.1 模块概览与容器说明 1
    1.1.1 核心模块列表 1
    1.1.2 模块容器说明 2
    1.2 MON (Monitor) 模块 2
    1.2.1 数据存放路径 2
    1.2.2 日志路径与内容 7
    1.2.3 日志相关参数 9
    1.2.4 MON 进程解析 11
    1.3 MGR (Manager) 模块 14
    1.3.1 数据存放路径 14
    1.3.2 日志路径与内容 14
    1.3.3 MGR 进程解析 17
    1.4 OSD模块 19
    1.4.1 数据存放路径 19
    1.4.2 日志路径与内容 23
    1.4.3 日志相关参数 26
    1.4.4 OSD 进程解析 26
    1.5 crash模块 28
    1.5.1 crash进程解析 28
    1.6 Cephadm Shell 30
  2. 客户端日志与监控 31
    2.1 RBD 客户端日志与监控 31
    2.1.1 网络通信层 31
    2.1.2 RBD 完成器 32
    2.1.3 RBD 对象缓存 33
    2.1.4 RBD 镜像 IO 统计 35
    2.1.5 Objecter (对象存储交互层) 36
    2.1.6 Throttle (限流机制) 38
    2.1.7 客户端运维建议总结 39
    2.2 其他客户端日志 40
    2.2.1 librados 日志 40
    2.2.2 Kernel (KRBD) 日志 40
  3. 通用日志配置与调试机制 41
    3.1 日志配置基础 41
    3.1.1 通用日志设置 41
    3.1.2 日志滚动与生命周期管理 43
    3.2 调试级别与子系统 44
    3.2.1 日志级别(1-20)与内存级别 44
    3.2.2 常用子系统默认级别对照表 44
    3.3 调试操作指南 50
    3.3.1 运行时动态调整 51
    3.3.2 启动时配置修改 51
    3.4 高级调试工具 52
    3.4.1 Valgrind 使用场景与限制 52
  1. Ceph 模块说明
    1.1 模块概览与容器说明
    在基于 cephadm 的容器化部署环境中,Ceph 集群的各个功能组件被封装为独立的 Docker 容器运行。这种架构利用 Systemd 管理容器生命周期,并通过宿主机的网络和存储命名空间实现高效通信。
    1.1.1 核心模块列表
    Ceph 存储集群主要由以下核心模块组成:
  1. MON
    维护集群状态的映射图(Map),包括 Monitor 图、OSD 图、MDS 图等。负责处理集群认证、选举以及集群状态的一致性维护。
  2. MGR
    负责监控集群状态、提供额外的监控接口(如 Prometheus、Dashboard)以及执行编排任务。它通常与 MON 一起部署。
  3. OSD
    Ceph 存储集群的核心组件,负责存储数据、处理数据复制、恢复和回填。每个 OSD 通常对应一个磁盘或存储设备。
  4. Crash
    崩溃收集模块,负责收集和存储各个守护进程崩溃时的堆栈信息和日志,便于故障分析。
  5. Cephadm
    虽然不是存储核心组件,但它是容器化部署的管理工具,负责容器的生命周期管理、编排和日志记录。
    1.1.2 模块容器说明
    在基于 cephadm 的部署环境中,Ceph 的各个核心功能模块(MON、MGR、OSD、Crash 等)均被封装为独立的 Docker 容器运行。每个模块都有其专属的守护进程(如 ceph-mon、ceph-osd)作为容器的入口程序。
    1.2 MON (Monitor) 模块
    1.2.1 数据存放路径
    数据目录位置
    进入到mon.node1

[ceph: root@node1 /]# mount | grep ceph
/dev/mapper/rhugo-root on /var/log/ceph type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/rhugo-root on /etc/ceph/ceph.conf type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
tmpfs on /run/ceph type tmpfs (rw,nosuid,nodev,size=3217412k,nr_inodes=819200,mode=755)
/dev/mapper/rhugo-root on /var/lib/ceph/crash type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
/dev/mapper/rhugo-root on /var/lib/ceph/mon/ceph-node1 type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)

Monitor 数据默认存储在/var/lib/ceph//mon.,并且通过上面的输出可以看到mon的数据存储在系统盘上。并且通过ceph device ls查看可以看到mon的数据存储在宿主机的系统盘vda上。

[ceph: root@node1 /]# ceph device ls
DEVICE HOST:DEV DAEMONS WEAR LIFE EXPECTANCY
2da358cf-4a30-4c0e-b node1:vda mon.node1

我们进入到/var/lib/ceph//mon.路径下查看一下有什么内容,里面有配置数据库(store.db),集群配置文件,密钥环等文件,而且都是存储在系统盘中。

├── mon.node1
│ ├── ceph_version_when_created
│ ├── config
│ ├── created_at
│ ├── external_log_to
│ ├── keyring
│ ├── kv_backend
│ ├── min_mon_release
│ ├── store.db
│ │ ├── 000027.log
│ │ ├── 000029.sst
│ │ ├── CURRENT
│ │ ├── IDENTITY
│ │ ├── LOCK
│ │ ├── MANIFEST-000015
│ │ ├── OPTIONS-000012
│ │ └── OPTIONS-000017
│ ├── unit.configured
│ ├── unit.created
│ ├── unit.image
│ ├── unit.meta
│ ├── unit.poststop
│ ├── unit.run
│ └── unit.stop

[root@node1 mon.node1]# ls
ceph_version_when_created external_log_to min_mon_release unit.created unit.poststop
config keyring store.db unit.image unit.run
created_at kv_backend unit.configured unit.meta unit.stop
[root@node1 mon.node1]# ls -la
total 56
drwx------ 3 ceph ceph 298 Jan 13 14:39 .
drwx------ 9 ceph ceph 198 Jan 13 14:35 …
-rw------- 1 ceph ceph 77 Jan 13 14:03 ceph_version_when_created
-rw------- 1 ceph ceph 322 Jan 13 14:15 config
-rw------- 1 ceph ceph 28 Jan 13 14:03 created_at
-rw------- 1 ceph ceph 5 Jan 13 14:39 external_log_to
-rw------- 1 ceph ceph 77 Jan 13 14:15 keyring
-rw------- 1 ceph ceph 8 Jan 13 14:03 kv_backend
-rw------- 1 ceph ceph 5 Jan 13 14:03 min_mon_release
drwxr-xr-x 2 ceph ceph 152 Jan 13 14:37 store.db
-rw------- 1 ceph ceph 38 Jan 13 14:15 unit.configured
-rw------- 1 ceph ceph 48 Jan 13 14:03 unit.created
-rw------- 1 root root 22 Jan 13 14:03 unit.image
-rw------- 1 root root 101 Jan 13 14:03 unit.meta
-rw------- 1 root root 334 Jan 13 14:03 unit.poststop
-rw------- 1 root root 1352 Jan 13 14:03 unit.run
-rw------- 1 root root 334 Jan 13 14:03 unit.stop
目录下包含的文件说明

  1. store.db/
    这是 MON 节点的数据库目录。Ceph MON 使用 RocksDB (默认) 或 LevelDB 来存储集群的“地图”数据,包括 Monitor Map、OSD Map、MDS Map、CRUSH Map 等。
    内部文件:
     CURRENT, MANIFEST-xxxxx, OPTIONS-xxxxx: RocksDB 的元数据和配置文件。
     *.sst (Sorted String Table): 存储实际数据的不可变文件。
     *.log: 预写日志(WAL),用于在崩溃后恢复数据,保证数据一致性。
     LOCK: 文件锁,防止多个进程同时操作该数据库。
    注意: 如果这个目录损坏或丢失,该 MON 节点将无法启动,且需要从其他 MON 节点同步数据来恢复。
  2. keyring
    这是存储 MON 节点的密钥环。它包含了该 MON 节点用于与集群其他组件(如其他 MON、OSD)进行身份验证和加密通信的密钥。
    注意: 如果此文件丢失或权限不正确,MON 将无法通过认证并加入集群。
  3. config
    通常包含该 MON 节点特有的配置参数。虽然 Ceph 通常集中管理配置(存储在 MON map 中),但在某些部署场景下,这里可能包含本地覆盖的配置或启动脚本注入的配置。
  4. kv_backend
    一个简单的文本文件,指明 MON 使用的是哪种键值存储后端(通常是 rocksdb 或 leveldb)。
  5. ceph_version_when_created
    记录创建该 MON 数据存储时所使用的 Ceph 版本号。这在升级过程中非常有用,帮助管理员确认数据结构的版本。
  6. min_mon_release
    记录该 MON 所需的最低兼容 Ceph 发布版本。这用于控制集群升级过程中允许的最低 MON 版本,防止旧版本的 MON 加入不兼容的新集群。
  7. created_at
    记录该 MON 存储目录创建的时间戳。
  8. external_log_to
    指示日志是否以及如何重定向到外部日志系统(如 journald 或 syslog)。
  9. unit.*
    unit.run通常是一个 systemd 单元文件的符号链接或副本,用于运行 MON 服务。
    unit.created, unit.configured, unit.stop, unit.poststop,这些是编排工具(如 cephadm 或类似的容器管理器)使用的标记文件或状态文件,用于跟踪该 MON 实例的生命周期状态(如已创建、已配置、已停止等)。
    unit.image记录运行该 MON 所使用的容器镜像 ID。
    unit.meta包含部署该单元时所需的元数据(如网络配置、FSID 等)。
    1.2.2 日志路径与内容
    日志文件位置
    monitor的日志在运行ceph集群的宿主机的 /var/log/ceph/ 路径下。集群默认不将mon日志写入文件,所以如果需要查看,则要先将该Monitor的log_to_file参数修改为true。
    日志文件在linux下有切割轮转,达到一定大小或者一定时间就执行切割和轮转,我们可以在宿主机中的/etc/logrotate.d下看到类似这个的文件ceph-,里面有关于切割轮转的配置,是由cephadm部署集群的时候生成的。

日志关键内容解读
以某一次的mon.node1.log为例,该日志文件是Ceph Monitor(mon)node1的日志文件,记录了 Ceph 集群中 Monitor 节点的运行状态、内部操作、客户端请求、数据库(RocksDB)的 compaction/flush 过程等关键信息。主要内容包括:

  1. Monitor 自身状态
    Leader 选举与角色:mon.node1@0(leader) 表示该节点是当前 Monitor 集群的 Leader。
    缓存配置:周期性输出 _set_new_cache_sizes,显示内存缓存分配情况(如 cache_siz
版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/3/12 8:48:08

手把手教你搭建STM32CubeMX点灯硬件电路(新手教程)

以下是对您提供的博文内容进行 深度润色与工程化重构后的版本 。全文已彻底去除AI腔调、模板化结构和教科书式罗列,转而以一位 有十年嵌入式实战经验的工程师高校课程设计者 的口吻娓娓道来——既有硬件焊点上的温度感,也有寄存器位操作时的指尖触感…

作者头像 李华
网站建设 2026/4/16 9:31:48

cv_resnet18_ocr-detection快速部署:Docker镜像使用详细步骤

cv_resnet18_ocr-detection快速部署:Docker镜像使用详细步骤 1. 模型与镜像简介 1.1 什么是cv_resnet18_ocr-detection? cv_resnet18_ocr-detection 是一个专为中文场景优化的轻量级OCR文字检测模型,基于ResNet-18主干网络构建&#xff0c…

作者头像 李华
网站建设 2026/4/14 6:28:58

Qwen3-Embedding-0.6B怎么用?Jupyter调用全流程保姆级教程

Qwen3-Embedding-0.6B怎么用?Jupyter调用全流程保姆级教程 你是不是也遇到过这些情况:想给自己的文档加语义搜索,但嵌入模型太大跑不动;想在本地快速验证文本相似度,却卡在环境配置上;或者刚下载了Qwen3-E…

作者头像 李华
网站建设 2026/3/31 7:07:30

Z-Image-Turbo图像生成实战:Python启动脚本与输出路径管理指南

Z-Image-Turbo图像生成实战:Python启动脚本与输出路径管理指南 1. 初识Z-Image-Turbo_UI界面 Z-Image-Turbo不是那种需要敲一堆命令、调一堆参数才能跑起来的“硬核”工具。它自带一个直观友好的图形界面,打开就能用,特别适合刚接触AI图像生…

作者头像 李华
网站建设 2026/4/15 9:38:01

【Termux】Photopea离线版部署

Photopea是捷克开发者Ivan Kutskir开发的免费浏览器端专业图像编辑器(2013年推出),界面与操作高度对标Photoshop,完全本地运行、无需上传文件、支持离线(PWA),同时提供付费去广告与可自行部署的…

作者头像 李华
网站建设 2026/3/11 3:28:56

【2026最新整合】C盘满了怎么清理?c盘瘦身只需这些简单步骤!

电脑用着用着就开始变卡、系统更新失败、甚至提示"磁盘空间不足"? 其实这都是因为——C盘太满了! C盘是系统盘,承载着Windows系统文件、临时缓存、更新补丁、用户数据等内容,一旦空间不足,就会导致运行缓慢…

作者头像 李华