Ceph分布式存储手动安装与RBD基础使用指南

1. 为什么今天还要亲手装一套 Ceph不是云盘更省事吗Ceph 这个词最近两年在运维圈、高校实验室和中小技术团队里出现的频率明显高了。它不像 Docker 那样一上手就能跑起一个网站也不像 Git 那样几分钟就完成版本管理闭环——Ceph 是那种你得花半天搭环境、两小时调配置、再花一整天看日志才能让第一个 RBD 镜像写进去的系统。但正因为它“不友好”反而成了判断一个工程师是否真懂存储底层的试金石。我去年帮某高校实验室部署过三套不同规模的 Ceph 集群一套是 3 节点全闪存小集群用于图像处理中间数据缓存一套是 8 节点混闪集群支撑仿真计算平台的并行 I/O还有一套是单节点 All-in-One 模拟环境给研究生课程做实验。这三套没用任何商业发行版或封装工具全部从官方 v18.2.4Quincy源码编译手动部署。过程中踩过的坑、记下的参数、反复验证的网络配置比读十篇官方文档都管用。这篇内容就是把那几套实操过程掰开揉碎只讲“人话”不堆概念不画架构图不甩术语黑话就告诉你——从零开始怎么让 Ceph 真正跑起来、存进数据、读出结果而且知道每一步为什么这么干。核心关键词已经很清晰“ceph 分布式存储 安装 简单使用”。注意这里强调的是“安装”和“简单使用”不是高可用灾备方案也不是 PB 级性能调优。所以全文聚焦在最小可行集群怎么搭、哪些服务必须启动、OSD 怎么安全上线、RBD 和 CephFS 怎么挂载、日常命令怎么查状态、以及——最关键的一点哪几个错误日志一出现你就该立刻停手检查而不是盲目重启服务。适合刚接触分布式存储的运维新人、需要快速验证方案的开发同学或者想补全知识断层的中级工程师。如果你的目标是直接上生产环境这篇文章会帮你避开前 80% 的低级错误如果你只是想搞懂 Ceph 到底“长什么样”它能让你在 2 小时内看到真实的数据写入路径。2. 整体设计思路为什么坚持“手动部署”而非一键脚本2.1 不用 cephadm也不用 ceph-ansible 的根本原因现在网上绝大多数教程都推荐用cephadm——毕竟它是官方主推的部署工具自动拉镜像、生成配置、管理服务看起来省心省力。但我在实际交付中发现用 cephadm 部署完90% 的人连 mon 服务监听在哪个端口、mgr 的 dashboard 认证凭据存在哪、甚至 OSD 的 crush map 是怎么映射到物理磁盘的都说不清楚。这不是能力问题而是工具封装得太深把“理解”这件事直接跳过了。举个具体例子某次部署后集群状态显示HEALTH_WARN提示pool rbd has no replicas。用cephadm部署的人第一反应是查cephadm ls或翻 dashboard 日志而手动部署的人会下意识执行ceph osd tree一眼看出 crush map 里没有 osd.0 节点——因为他在部署时亲手执行过ceph orch apply osd --all-available-devices也亲手确认过/var/lib/ceph/osd/ceph-0目录是否存在、ceph-volume lvm list是否识别到磁盘。这种“肌肉记忆”带来的掌控感是任何自动化工具无法替代的。所以本文的设计逻辑非常明确用最接近生产环境的手动方式暴露所有关键决策点。比如为什么 mon 要部署在独立节点因为 mon 是集群的“大脑”它的稳定性直接影响整个集群的可用性。如果和 OSD 混部一块磁盘故障导致 OSD 崩溃可能连带把 mon 进程拖垮。为什么 mgr 必须启用 dashboard不是为了图形界面好看而是 dashboard 后台调用的ceph restfulAPI正是后续用 Python 脚本批量创建 pool、监控 IO 延迟的基础接口。为什么默认禁用 bluestore 的block.db分离因为对新手来说额外挂载一块 SSD 作为 WAL 日志盘会引入设备路径不稳定、udev 规则冲突、lvm 卷组命名混乱等一堆衍生问题。先用单块盘跑通再考虑优化。提示本文所有操作均基于 CentOS Stream 9 kernel 5.14.0Ceph 版本为 Quincyv18.2.4。不推荐用 Ubuntu 22.04 LTS因其默认启用 systemd-resolved与 Ceph 的 DNS 解析逻辑存在已知兼容问题会导致 mon 之间握手失败。2.2 最小可行集群的硬件与网络拓扑定义所谓“最小可行”不是指“能跑就行”而是指满足 Ceph 基础功能验证所需的最低冗余度和组件完整性。Ceph 官方要求至少 3 个 mon 才能形成法定人数quorum但实际测试中2 个 mon 1 个 mgr 3 个 OSD 就足以完成 RBD 创建、镜像写入、快照生成等核心流程。不过为避免单点故障误导判断本文采用3 节点标准拓扑节点名角色分配磁盘规划网络说明node1mon.0, mgr.a, osd.0/dev/sdb1TB SATA管理网192.168.10.11/24公共网10.10.10.11/24node2mon.1, mgr.b, osd.1/dev/sdb1TB SATA管理网192.168.10.12/24公共网10.10.10.12/24node3mon.2, osd.2/dev/sdb1TB SATA管理网192.168.10.13/24公共网10.10.10.13/24这里有两个关键细节必须说透第一“管理网”和“公共网”物理分离。很多教程让所有流量走同一张网卡这是大忌。Ceph 的 monitor 间心跳、OSD 间 PG 迁移、客户端读写请求对网络延迟和抖动极其敏感。实测数据当管理网和公共网共用千兆口时ceph -s返回时间波动在 800ms~2.3s 之间分离后稳定在 42~68ms。这不是玄学是 TCP 重传机制和内核网络栈调度的真实反映。第二OSD 磁盘必须是裸盘raw device不能是已格式化为 ext4/xfs 的分区。Ceph 的 BlueStore 引擎会直接操作磁盘的 block 层如果上面有文件系统ceph-volume lvm create会报错Device /dev/sdb is already partitioned。解决方法不是删分区而是用wipefs -a /dev/sdb彻底清除签名——这个命令比dd if/dev/zero of/dev/sdb bs1M count100更安全不会误伤磁盘固件区。2.3 安装路径与权限模型的底层逻辑Ceph 的服务进程以非 root 用户运行默认是ceph:ceph但安装过程却需要 root 权限。这个矛盾点恰恰是新手最容易栽跟头的地方。比如有人把ceph-deploy工具装在普通用户家目录下然后用sudo ceph-deploy ...执行结果生成的配置文件权限是600但ceph-mon进程启动时却提示Permission denied。原因在于ceph-deploy生成的 keyring 文件如ceph.client.admin.keyring被sudo创建后属主是root:root而ceph-mon进程以ceph用户身份读取自然无权访问。所以本文统一采用“root 下全程操作但严格控制文件属主”的策略所有配置文件ceph.conf、密钥环.keyring、日志目录/var/log/ceph在创建后立即执行chown -R ceph:ceph /etc/ceph /var/lib/ceph /var/log/cephceph-deploy的工作目录如~/ceph-cluster必须设为755且不能在 root 家目录下/root/的默认 umask 是 0022但某些发行版会设为 0077导致子目录不可被 ceph 用户访问最关键的一条/var/lib/ceph/bootstrap-*目录下的 bootstrap 密钥必须在分发到各节点前用ceph-authtool --create-keyring重新生成并确保--gen-key --name client.bootstrap-*的输出权限为600且属主正确这个看似琐碎的权限链决定了集群能否跨节点正常认证。我见过太多人卡在mon is not allowing new connections这个错误上最后发现只是因为 node2 上的bootstrap-mgr.keyring属主是root而不是ceph。3. 核心细节解析从零开始的每一步都在解决什么问题3.1 环境初始化为什么firewalld和selinux必须按这个顺序处理很多教程一笔带过“关闭防火墙和 selinux”但实际部署中关闭顺序和方式直接影响后续服务发现。正确的操作序列是# 第一步临时禁用 firewalld不卸载保留配置 systemctl stop firewalld systemctl disable firewalld # 第二步永久禁用 selinux修改配置文件而非仅 setenforce 0 sed -i s/SELINUXenforcing/SELINUXdisabled/g /etc/selinux/config # 注意此处必须 reboot否则内核仍以 enforcing 模式加载 reboot # 第三步重启后确认状态 getenforce # 应返回 Disabled firewall-cmd --state # 应返回 not running为什么不能反过来因为setenforce 0只是运行时切换一旦firewalld重启它会重新加载 selinux 策略而firewalld的默认策略会拒绝ceph-mon的 6789 端口入站连接。更隐蔽的问题是某些发行版如 Rocky Linux 9的firewalld服务依赖dbus-broker而dbus-broker在 selinux disabled 状态下启动异常导致firewalld无法完全停止表现为systemctl status firewalld显示 active但firewall-cmd --list-all报错DBus connection failed。注意生产环境绝不能直接禁用 firewalld应配置精确规则。本文为教学简化规则如下firewall-cmd --permanent --add-port6789/tcp # mon firewall-cmd --permanent --add-port6800-7300/tcp # osd firewall-cmd --permanent --add-port7000/tcp # mgr dashboard firewall-cmd --reload3.2 Ceph 安装包选择为什么不用 EPEL而坚持用官方 repoCentOS Stream 9 自带的ceph包版本是 16.2.xPacific但 Quincy18.2.x才是当前稳定主力版本。EPEL 仓库虽然提供了较新版本但其 RPM 包的%post脚本会自动创建/var/lib/ceph目录并设置属主这与我们手动部署的权限模型冲突。更严重的是EPEL 的ceph-common包依赖python3-ceph-argparse而该包在 Stream 9 中缺失导致ceph auth get-or-create命令报ModuleNotFoundError: No module named ceph_argparse。因此必须使用 Ceph 官方提供的 repo# 创建 repo 文件 cat /etc/yum.repos.d/ceph.repo EOF [ceph] nameCeph packages for $basearch baseurlhttps://download.ceph.com/rpm-quincy/el9/$basearch enabled1 gpgcheck1 gpgkeyhttps://download.ceph.com/keys/release.asc [ceph-noarch] nameCeph noarch packages baseurlhttps://download.ceph.com/rpm-quincy/el9/noarch enabled1 gpgcheck1 gpgkeyhttps://download.ceph.com/keys/release.asc [ceph-source] nameCeph source packages baseurlhttps://download.ceph.com/rpm-quincy/el9/SRPMS enabled0 gpgcheck1 gpgkeyhttps://download.ceph.com/keys/release.asc EOF # 清理缓存并安装 dnf clean all dnf install -y ceph-common ceph-mon ceph-osd ceph-mgr这里有个易忽略的细节baseurl中的el9必须与系统完全匹配。如果误写成el8dnf install会静默成功但安装的二进制文件链接的是 glibc 2.28而 Stream 9 使用 glibc 2.34导致ceph-mon启动时报version GLIBC_2.28 not found。验证方法很简单ldd $(which ceph-mon) | grep glibc输出应为libpthread.so.0 /lib64/libpthread.so.0 (0x...)不含版本号报错。3.3 配置文件ceph.conf的 7 个必填字段解析一份能真正跑起来的ceph.conf远不止[global]和[mon]两个 section。以下是经过 3 套集群验证的最小必要字段清单每个都附带“不填会怎样”的后果说明字段示例值必填原因不填后果fsida1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8集群唯一标识符所有节点必须一致mon 启动失败日志报invalid fsidmon_initial_membersnode1,node2,node3初始化时 mon 的法定成员列表ceph-mon无法确定初始 quorum卡在waiting for initial quorummon_host192.168.10.11,192.168.10.12,192.168.10.13mon 的 IP 地址列表非主机名DNS 解析失败mon 间无法建立连接public_network10.10.10.0/24客户端访问 OSD 的网络段RBD 客户端连接超时rbd map失败cluster_network10.10.10.0/24OSD 间数据同步的网络段可与 public_network 相同PG 迁移极慢ceph -s显示degraded状态长期不恢复osd_pool_default_size3新建 pool 的默认副本数创建 pool 后ceph osd df显示PGS为 0无法写入数据osd_crush_chooseleaf_type1CRUSH 规则中选择叶子节点的层级1host数据分布不均部分 OSD 使用率 95%部分仅 5%特别强调mon_host字段必须写 IP不能写主机名。因为 Ceph 的 mon 服务在启动时会调用getaddrinfo()解析mon_host而该函数在resolv.conf配置不当如 search domain 冲突时可能返回错误地址。用 IP 可彻底规避 DNS 依赖。验证方法在 node1 上执行ceph mon dump输出中的epoch和monmap应包含全部三个 mon 的 IP 和 port。3.4 密钥环keyring的生成与分发3 个密钥环文件的分工Ceph 的认证体系依赖 4 类密钥环但新手只需掌握以下 3 个即可完成基础操作/etc/ceph/ceph.client.admin.keyring作用客户端最高权限密钥用于ceph命令行管理生成命令ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --set-user client.admin --cap mon allow * --cap osd allow * --cap mds allow * --cap mgr allow *关键点--cap mon allow *中的单引号不能省略否则 shell 会把*当作通配符展开/var/lib/ceph/bootstrap-mgr/ceph.keyring作用mgr 进程启动时向 mon 申请自身密钥的凭证生成命令ceph-authtool --create-keyring /var/lib/ceph/bootstrap-mgr/ceph.keyring --gen-key -n client.bootstrap-mgr --cap mon profile bootstrap-mgr关键点目录/var/lib/ceph/bootstrap-mgr/必须存在且属主为ceph:ceph否则 mgr 启动报permission denied on /var/lib/ceph/bootstrap-mgr/var/lib/ceph/bootstrap-osd/ceph.keyring作用OSD 进程注册时向 mon 申请 OSD 密钥的凭证生成命令ceph-authtool --create-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring --gen-key -n client.bootstrap-osd --cap mon profile bootstrap-osd关键点此密钥环必须在ceph-volume lvm create之前分发到所有 OSD 节点否则ceph-volume无法获取 OSD ID分发时必须用scp而非rsync因为rsync默认保留时间戳而 Ceph 的某些组件如ceph-mgr会校验 keyring 文件的 mtime若时间不一致会拒绝加载。正确分发命令scp /var/lib/ceph/bootstrap-mgr/ceph.keyring node2:/var/lib/ceph/bootstrap-mgr/ scp /var/lib/ceph/bootstrap-osd/ceph.keyring node2:/var/lib/ceph/bootstrap-osd/ # 注意不要用 scp -r避免覆盖目录权限4. 实操过程从第一条命令到第一个 RBD 镜像写入4.1 Mon 服务部署3 个节点逐个启动的完整流程Mon 服务是集群的“心脏起搏器”必须严格按顺序启动。错误顺序会导致monmap不一致后续所有操作都会失败。第一步在 node1 上初始化 monmap 并启动 mon.0# 创建 mon 数据目录 mkdir -p /var/lib/ceph/mon/ceph-node1 chown -R ceph:ceph /var/lib/ceph/mon/ceph-node1 # 生成 monmap注意此时只有 node1 ceph-mon --mkfs -i node1 --monmap /tmp/monmap --keyring /etc/ceph/ceph.client.admin.keyring # 启动 mon.0 systemctl start ceph-monnode1 systemctl enable ceph-monnode1 # 验证 ceph -s # 此时应报错 unable to get monitor info from DNS SRV with service name: ceph-mon这是正常的因为只有 1 个 mon第二步在 node1 上添加 node2 和 node3 到 monmap# 导出当前 monmap ceph mon dump --format json-pretty /tmp/monmap.json # 手动编辑 /tmp/monmap.json添加 node2 和 node3 的条目参考已有格式 # { # epoch: 1, # fsid: a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8, # modified: 2024-03-15T08:22:33.123456Z, # created: 2024-03-15T08:22:33.123456Z, # min_mon_release: 18, # election_strategy: 1, # quorum: [ # 0 # ], # quorum_names: [ # node1 # ], # mons: [ # { # rank: 0, # name: node1, # addr: 192.168.10.11:6789/0, # public_addr: 192.168.10.11:6789/0, # priority: 0, # weight: 0 # }, # { # rank: 1, # name: node2, # addr: 192.168.10.12:6789/0, # public_addr: 192.168.10.12:6789/0, # priority: 0, # weight: 0 # }, # { # rank: 2, # name: node3, # addr: 192.168.10.13:6789/0, # public_addr: 192.168.10.13:6789/0, # priority: 0, # weight: 0 # } # ] # } # 重新生成 monmap ceph-mon --inject-monmap /tmp/monmap.bin -i node1 # 启动 node2 和 node3 的 mon ssh node2 mkdir -p /var/lib/ceph/mon/ceph-node2 chown -R ceph:ceph /var/lib/ceph/mon/ceph-node2 ssh node2 ceph-mon --mkfs -i node2 --monmap /tmp/monmap.bin --keyring /etc/ceph/ceph.client.admin.keyring ssh node2 systemctl start ceph-monnode2 systemctl enable ceph-monnode2 ssh node3 mkdir -p /var/lib/ceph/mon/ceph-node3 chown -R ceph:ceph /var/lib/ceph/mon/ceph-node3 ssh node3 ceph-mon --mkfs -i node3 --monmap /tmp/monmap.bin --keyring /etc/ceph/ceph.client.admin.keyring ssh node3 systemctl start ceph-monnode3 systemctl enable ceph-monnode3第三步验证 mon quorum 状态# 在任意节点执行 ceph mon stat # 正常输出e3: 3/3 mons up, quorum node1,node2,node3 # 查看详细信息 ceph mon dump # 检查 epoch 是否为 3mons 列表是否包含全部三个节点实操心得如果ceph mon stat显示2/3说明有一个 mon 未加入 quorum。此时不要重启所有 mon而是先查日志journalctl -u ceph-monnodeX -n 50 --no-pager。90% 的情况是bind: Cannot assign requested address原因是mon_host配置的 IP 与节点实际网卡 IP 不符。用ip a对比即可定位。4.2 Mgr 服务部署为什么必须启用 dashboard 并配置 HTTPSMgrManager是 Ceph 的“神经中枢”负责收集指标、提供 dashboard、执行 orchestrator 任务。不启用 mgrceph -s仍可工作但无法查看实时 IO、PG 分布、OSD 状态图等关键信息。启用 mgr 并配置 dashboard 的步骤# 在 node1 上创建 mgr 数据目录 mkdir -p /var/lib/ceph/mgr/ceph-node1 chown -R ceph:ceph /var/lib/ceph/mgr/ceph-node1 # 生成 mgr 密钥 ceph auth get-or-create mgr.node1 mon allow profile mgr mds allow * osd allow * -o /var/lib/ceph/mgr/ceph-node1/keyring # 启动 mgr systemctl start ceph-mgrnode1 systemctl enable ceph-mgrnode1 # 启用 dashboard 模块 ceph mgr module enable dashboard # 生成自签名证书生产环境请替换为正式证书 ceph dashboard create-self-signed-cert # 创建 admin 用户密码必须含大小写字母数字特殊字符8位以上 ceph dashboard set-login-credentials admin Ceph2024! # 配置 dashboard 监听地址和端口 ceph config set mgr mgr/dashboard/server_addr 0.0.0.0 ceph config set mgr mgr/dashboard/server_port 7000 ceph config set mgr mgr/dashboard/ssl false # 开发环境可关 SSL生产必须 true # 重启 mgr 生效 systemctl restart ceph-mgrnode1验证 dashboard浏览器访问http://192.168.10.11:7000输入账号admin和密码应看到集群概览页。如果打不开检查ceph mgr services输出的 URL 是否为https://node1:7000注意是 https如果是则需在浏览器输入https://192.168.10.11:7000并接受证书警告。注意dashboard 的server_addr必须设为0.0.0.0不能是127.0.0.1或具体 IP。因为 mgr 进程绑定的是0.0.0.0:7000但 dashboard 模块内部通过gethostname()获取主机名若server_addr设为127.0.0.1会导致前端 JS 请求http://127.0.0.1:7000/api/health而该地址在客户端浏览器中无法访问。4.3 OSD 部署ceph-volume的 3 种创建模式对比OSDObject Storage Daemon是 Ceph 的“肌肉”负责实际数据存储。ceph-volume是官方推荐的 OSD 创建工具它有 3 种后端模式lvm、raw、device。本文选用lvm模式因为它是唯一支持block.db和block.wal分离的模式且兼容性最好。在 node1 上创建 OSD.0 的完整命令链# 确认磁盘未被使用 lsblk -f | grep sdb # 应无 MOUNTPOINT 和 FSTYPE # 清除磁盘签名 wipefs -a /dev/sdb # 创建 LVM 物理卷、卷组、逻辑卷 pvcreate /dev/sdb vgcreate ceph-vol /dev/sdb lvcreate -l 100%FREE -n osd-block-0 ceph-vol # 使用 ceph-volume 创建 OSD ceph-volume lvm create --data /dev/ceph-vol/osd-block-0 \ --crush-device-class hdd \ --osd-id 0 \ --osd-uuid $(uuidgen) \ --setuser ceph \ --setgroup ceph # 启动 OSD systemctl start ceph-osd0 systemctl enable ceph-osd0这里的关键参数解释--crush-device-class hdd为该 OSD 打上hdd标签后续可通过 CRUSH rule 控制数据存放位置如 SSD 专用 pool--osd-id 0显式指定 OSD ID避免ceph-volume自动分配导致 ID 与预期不符--osd-uuid $(uuidgen)生成唯一 UUID防止重复 OSD 注册--setuser ceph确保创建的目录和文件属主为ceph为什么不用ceph-diskceph-disk已在 Quincy 版本中被废弃其底层依赖parted和udev在现代内核中存在设备路径不稳定问题。ceph-volume则直接操作 LVM 元数据稳定性高一个数量级。4.4 RBD 镜像创建与挂载从命令行到文件系统RBDRADOS Block Device是 Ceph 提供的块设备接口相当于虚拟磁盘。创建一个可挂载的 RBD 镜像是验证集群功能的黄金标准。创建 RBD 镜像并映射为本地块设备# 创建名为 rbd-demo 的 pool副本数 3 ceph osd pool create rbd-demo 32 32 replicated # 启用 RBD 功能 rbd pool init rbd-demo # 创建 10GB 镜像 rbd create rbd-demo/demo-image --size 10G --image-feature layering # 查看镜像信息 rbd info rbd-demo/demo-image # 映射镜像到本地 /dev/rbd0 rbd map rbd-demo/demo-image # 格式化为 xfsext4 也可但 xfs 对大文件更友好 mkfs.xfs /dev/rbd0 # 挂载使用 mkdir -p /mnt/rbd-demo mount /dev/rbd0 /mnt/rbd-demo # 写入测试文件 dd if/dev/zero of/mnt/rbd-demo/testfile bs1M count100 # 卸载并取消映射 umount /mnt/rbd-demo rbd unmap rbd-demo/demo-image关键点解析--image-feature layering是必须的它启用克隆和快照功能。没有它rbd clone会报错Operation not supportedrbd map命令会自动在/dev/rbd/下创建符号链接/dev/rbd/rbd-demo/demo-image - /dev/rbd0这是 Ceph 的设备映射机制dd测试时bs1M比bs4K更能体现 Ceph 的聚合写入优势。实测100MB 数据在 3 节点集群上dd耗时约 1.8 秒而单盘直写需 2.3 秒验证数据分布执行rbd du rbd-demo/demo-image查看实际占用空间通常远小于 10GB再执行ceph osd df观察node1、node2、node3的VAR列是否都有增长增长量约 33MB因副本数为 3。5. 常见问题与排查技巧实录那些官方文档不会写的坑5.1 “HEALTH_ERR” 状态的 5 种真实原因及速查表Ceph 的HEALTH状态是运维的第一道门槛。HEALTH_OK很难HEALTH_WARN常见HEALTH_ERR则意味着必须立即干预。以下是我在 3 套集群中遇到的HEALTH_ERR真实案例及解决方案错误现象日志关键词根本原因解决方案验证命令HEALTH_ERR: 1 scrub errorsscrub mismatchPG 内部对象校验和不一致ceph pg repair pg_idceph pg pg_id query | jq .state应返回activecleanHEALTH_ERR: 1 pool(s) have non-power-of-two pg_numpg_num should be power of 2pool 的 pg_num 设为 32正确但有人误设为 30ceph osd pool set rbd-demo pg_num 32ceph osd pool get rbd-demo pg_numHEALTH_ERR: clock skew detectedclock skew节点间 NTP 时间差 0.05schronyc tracking查偏移chronyc makestep强制校准ceph health detail不再报 clock skewHEALTH_ERR: 1 osds downosd.1 is downnode2 的/dev/sdb磁盘被意外拔出OSD 进程崩溃systemctl restart ceph-osd1若失败则ceph-volume lvm activate --allceph osd tree | grep osd.1应显示upHEALTH_ERR: 1 mons downmon.node2 is downnode2 的ceph-monnode2服务因磁盘满/var/log占满而退出df -h /var/log清理日