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

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/1221369.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

FSMN VAD语音持续时长计算:end-start公式应用实例

FSMN VAD语音持续时长计算:end-start公式应用实例 1. 什么是FSMN VAD?一句话说清它的用处 FSMN VAD是阿里达摩院FunASR项目中开源的语音活动检测模型,全称是“前馈序列记忆网络语音活动检测器”。它不生成文字,也不识别说话内容…

STM32多通道UART同时工作的资源分配策略

以下是对您提供的博文内容进行 深度润色与工程化重构后的版本 。全文已彻底去除AI生成痕迹,语言更贴近一位深耕嵌入式多年、常驻产线调试现场的资深工程师口吻;结构上打破传统“引言-原理-代码-总结”的刻板范式,以真实项目痛点切入&#x…

FSMN VAD降本方案:低成本GPU部署,推理速度提升33倍

FSMN VAD降本方案:低成本GPU部署,推理速度提升33倍 1. 为什么需要一个“能用又省钱”的VAD方案? 你有没有遇到过这样的情况:想在边缘设备或小成本服务器上跑语音活动检测(VAD),但主流方案要么…

如何联系科哥技术支持?unet开发者沟通渠道指南

如何联系科哥技术支持?UNet人像卡通化工具开发者沟通渠道指南 你刚用上这款基于UNet架构的人像卡通化工具,界面清爽、操作简单,上传一张照片,几秒就生成一张风格鲜明的卡通头像——但突然遇到模型加载失败、批量处理卡在87%、或者…

Paraformer-large语音识别质量评估:WER计算实战方法

Paraformer-large语音识别质量评估:WER计算实战方法 1. 为什么需要WER评估语音识别效果 你刚部署好Paraformer-large离线版,上传一段会议录音,几秒后屏幕上跳出一行文字:“今天我们要讨论下季度的市场策略和预算分配”。看起来挺…

告别游戏语言障碍:XUnity自动翻译器让全球游戏触手可及

告别游戏语言障碍:XUnity自动翻译器让全球游戏触手可及 【免费下载链接】XUnity.AutoTranslator 项目地址: https://gitcode.com/gh_mirrors/xu/XUnity.AutoTranslator 一、三大痛点:外语游戏真的玩不明白?🙋♂️ 剧情理…

4步采样出图!Qwen-Image-2512-ComfyUI实战分享

4步采样出图!Qwen-Image-2512-ComfyUI实战分享 1. 为什么是Qwen-Image-2512?中文生成不再“翻车” 你有没有试过这样描述:“水墨风格的杭州西湖断桥残雪,远处雷峰塔若隐若现,一位穿青衫的古人撑油纸伞缓步而行&#…

STM32CubeMX时钟配置实战:从零实现LSE精准校准

以下是对您提供的博文内容进行 深度润色与结构优化后的版本 。我以一名资深嵌入式系统工程师兼技术博主的身份,彻底重构了原文的逻辑脉络、语言风格与教学节奏——目标是: 消除AI痕迹、增强实战代入感、提升技术纵深感、强化可复现性,并让…

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…

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

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

Java中使用Scanner类的next()和nextLine()常见的几个陷阱

在JavaSE阶段的学习里,在练习一些知识点时,经常需要使用Scanner来在控制台输入内容 但是在使用的过程中,会遇到一些坑。对于Scanner,以下的几点一定要知道! 1、next()会把空格当做结束符。所以你使用next()来接收用户…

2026清洗机网带优质生产厂家推荐:流水线输送网带、流水线输送链板、烘干机网带、烘干输送链板、网带转弯机、网带输送机选择指南

2026清洗机网带优质生产厂家推荐行业背景与筛选依据根据《2026-2030年中国输送网带行业发展白皮书》数据,随着食品、医药、电子等行业生产标准的严苛化升级,清洗机专用网带的市场需求年复合增长率达12.7%,成为输送网…

unet image Face Fusion日志查看方法?错误排查信息定位技巧

unet image Face Fusion日志查看方法?错误排查信息定位技巧 1. 为什么需要掌握日志查看和错误定位 当你在使用 unet image Face Fusion 进行人脸融合时,偶尔会遇到“点击开始融合没反应”“页面卡在加载中”“融合结果一片黑”“报错提示一闪而过”这类…

GPT-OSS-20B医疗领域尝试:病历摘要生成实验

GPT-OSS-20B医疗领域尝试:病历摘要生成实验 1. 为什么选GPT-OSS-20B做病历摘要? 在医疗AI落地场景中,病历摘要生成是个既刚需又难啃的骨头——既要准确提取关键临床信息(比如主诉、诊断、用药、检查结果)&#xff0c…

FSMN-VAD适合嵌入式设备吗?算力需求与优化建议

FSMN-VAD适合嵌入式设备吗?算力需求与优化建议 1. 什么是FSMN-VAD:轻量语音“开关”检测器 你有没有遇到过这样的问题:语音识别系统总在静音时乱触发,或者长录音里混着大段空白,手动剪切又费时费力?FSMN-…

Z-Image-Turbo图像生成避坑指南:新手常见错误汇总

Z-Image-Turbo图像生成避坑指南:新手常见错误汇总 1. 初识Z-Image-Turbo_UI界面:别被第一眼迷惑 刚打开Z-Image-Turbo的UI界面时,很多人会愣一下——这看起来太“朴素”了。没有炫酷的动画,没有复杂的菜单栏,只有几个…

如何用Open-AutoGLM实现手机自动化?保姆级部署教程

如何用Open-AutoGLM实现手机自动化?保姆级部署教程 你有没有想过,让AI替你点开APP、搜索内容、填写表单、甚至完成购物下单?不是靠预设脚本,而是真正“看懂”屏幕、“听懂”指令、“想清楚”步骤,再动手执行——这不再…

PixelStreamingInfrastructure https

PixelStreamingInfrastructure httpsSignallingWebServer前端网页服务器✅ 必改SignallingWebRTC 信令服务器(WS)✅ 必改SFUWebRTC 媒体转发⚠ 可能要Frontend前端 JS 连接地址✅ 必改

Transformer学习笔记(位置编码)

一. 关于位置编码:pos表示token位置,2i和2i1表示维度下标(奇偶)可以看出,随着i越来越接近d/2(维度越来越往下),位置编码的值随着位置pos变换的幅度越大(正余弦周期越大),…

网络安全知识汇总

针对网络工程师的网络安全知识需求,开展全面汇总与总结,提取关键要点,助力读者精准学习、高效掌握。资料以电子形式呈现,方便读者通过手机随时随地查阅,无需依赖纸质书籍检索,且内容完整系统,避…