存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载Ceph 是一个分布式对象、块与文件存储平台其高可用与高可靠性建立在容错式的软硬件故障管理之上。本指南围绕 Ceph 集群中两个最关键的监控对象——OSDObject Storage Daemon对象存储守护进程与 PGPlacement Group放置组——展开系统讲解 OSD 的in/out、up/down状态语义、PG 的完整状态机从creating到activeclean、Acting Set / Up Set 集合、Peering 过程以及 stuck 问题 PG 的识别方法。读完本文你将掌握一套可直接落地的监控命令集ceph osd stat、ceph osd tree、ceph pg stat、ceph pg dump_stuck、ceph osd map等并能结合相关配置参数mon_osd_down_out_interval、osd_max_backfills、osd_recovery_max_active等读懂集群健康状态、定位故障根源并做出初步处置。先记住一条原则集群某处发生故障可能使你无法访问某个特定对象但这并不代表你无法访问其他对象。遇到故障时不要惊慌按本文的步骤依次监控 OSD 和放置组再开始故障排查。Ceph 具备自我修复能力但当问题持续存在时监控 OSD 和 PG 将帮助你定位问题所在。OSD 状态模型in/out与up/down的四象限Ceph 中每个 OSD 都同时具有两个正交的状态维度in/out服务状态OSD 是否在集群服务范围内。in表示该 OSD 处于服务中客户端可以读写其上的数据out表示该 OSD 已退出服务CRUSH 不会再为其分配 PG。up/down运行状态OSD 守护进程是否正在运行且可被访问。up表示运行中且可达down表示未运行或不可达。两者组合形成如下状态矩阵原文档 ditaa 示意图的文本版---------------- ---------------- | OSD #n In | | OSD #n Up | ---------------- ---------------- ^ ^ | | v v ---------------- ---------------- | OSD #n Out | | OSD #n Down | ---------------- ----------------需要理解的关键语义若 OSD 曾是in后因故障或人工操作被置为outCeph 会将 PG 迁移到其他 OSD 以维持配置的冗余度。若 OSD 是outCRUSH 将不再向其分配 PG若 OSD 是down它必然同时是out。down且in是一个异常组合一旦出现这种情况说明该 OSD 未运行却在服务范围内集群处于不健康状态。何时集群不显示HEALTH OK是正常的运行ceph health、ceph -s或ceph -w时你可能会发现集群并不总是显示HEALTH OK。以下情形属于预期内、正常的非健康状态无需恐慌集群尚未启动。集群刚启动或重启PG 正在创建、OSD 正在 Peering尚未就绪。刚刚添加或移除了 OSD。刚刚修改了集群地图cluster map。监控 OSD确认每个in的 OSD 都在运行OSD 是否up且正在运行是监控 OSD 的重要方面只要集群处于运行状态每个处于in状态的 OSD 都应当是up的。检查全部 OSD 运行状态执行ceph osd stat输出格式为x osds: y up, z in; epoch: eNNNN含义如下字段含义x集群中 OSD 的总数y处于up状态的 OSD 数z处于in状态的 OSD 数eNNNN当前 osdmap 的 epoch地图版本号若in的数量大于up的数量说明有ceph-osd守护进程未运行。用以下命令找出具体是哪些ceph osd tree示例输出#ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF -1 2.00000 pool openstack -3 2.00000 rack dell-2950-rack-A -2 2.00000 host dell-2950-A1 0 ssd 1.00000 osd.0 up 1.00000 1.00000 1 ssd 1.00000 osd.1 down 1.00000 1.00000ceph osd tree以 CRUSH 层次结构pool → rack → host → osd展示每个 OSD 的STATUS列up/down、REWEIGHT与PRI-AFF主亲和性。排查技巧善用设计良好的 CRUSH 层次结构来定位特定 OSD 的物理位置能显著加速故障定位。若某个 OSD 处于down状态用 systemd 启动它以osd.1为例sudo systemctl start ceph-osd1对于 OSD 已停止或无法重启的问题参见 OSD Not Running 排查文档。PG 集合Acting Set 与 Up Set当 CRUSH 将 PG 分配给 OSD 时会根据池所需的副本数把每个副本分配到不同的 OSD上。例如池要求 3 个副本时CRUSH 可能将三个副本分别分配给osd.1、osd.2、osd.3。CRUSH 追求的是考虑了你所设置的故障域的伪随机放置因此在大型集群中PG 的各个副本很少落在相邻的 OSD 上。Ceph 用两组集合描述 PG 与 OSD 的关系Acting Set执行集合当前持有该 PG 分片完整且可用版本、负责处理客户端请求的 OSD 集合。Up Set上行集合包含该 PG 某一分片的 OSD 集合。数据正在被迁移、或计划被迁移到 Up Set。更多背景参见 Placement Group 概念。何时 Acting Set 与 Up Set 不一致通常情况下两者完全相同。当它们不一致时可能意味着Ceph 正在迁移 PG即 PG 被 remapped某个 OSD 正在恢复recovering集群存在问题此时 Ceph 通常会显示HEALTH WARN并伴随 stuck stale 消息。另一种常见情形是 Acting Set 中的某个 OSDdown或无法服务请求例如你添加或移除了 OSDCRUSH 将 PG 重新分配给其他 OSD重组了 Acting Set并通过backfill背填流程触发数据迁移某个 OSDdown后重启正处于recovering状态Acting Set 中某个 OSDdown或无法服务请求另一个 OSD 临时接管了它的职责。列出集群所有 PGceph pg dump查看某个 PG 的 Acting Set 与 Up Setceph pg map {pg-num}输出提供 osdmap epocheNNN、PG 编号{pg-num}、Up Setup[]与 Acting Setacting[]osdmap eNNN pg {raw-pg-num} ({pg-num}) - up [0,1,2] acting [0,1,2]注意若 Up Set 与 Acting Set 不匹配可能意味着集群正在自我再平衡也可能意味着集群存在问题。PeeringPG 进入active状态的前提在向 PG 写入数据之前PG 必须处于active状态且最好处于clean状态。为了确定 PG 的当前状态必须执行Peering对等即 PG 的 primary OSDActing Set 中的第一个 OSD与 secondary 及其后续 OSD 进行对等协商就 PG 的当前状态达成共识。下图假设池有 3 个副本--------- --------- ------- | OSD 1 | | OSD 2 | | OSD 3 | --------- --------- ------- | | | | Request To | | | Peer | | |--------------| | |--------------| | | Peering | | | | | | Request To | | Peer | |-----------------------------| |-----------------------------| | Peering |OSD 同时也会向 monitor 上报自身状态相关机制参见 Monitor/OSD 交互配置。Peering 故障排查参见 failures-osd-peering。监控 PG 状态运行ceph health、ceph -s或ceph -w时集群可能不显示HEALTH OK。在确认 OSD 运行正常之后还应当检查 PG 状态。以下与 PG 对等相关的场景中集群不显示HEALTH OK是正常现象刚刚创建了池PG 尚未完成 PeeringPG 正在恢复recovering刚刚向集群添加或移除了 OSD刚刚修改了 CRUSH 地图PG 正在迁移PG 的不同副本之间存在不一致数据Ceph 正在对 PG 的副本执行 scrub清理/校验Ceph 没有足够的存储容量完成背填backfill操作。这些情形导致HEALTH WARN时不必恐慌多数情况下集群会自行恢复但某些情况下需要人工介入。监控 PG 的重点是检查其状态是否为active且clean即集群运行时所有 PG 都应处于active状态且最好是clean。查看每个 PG 的状态ceph pg stat输出格式为x pgs: y activeclean; z bytes data, aa MB used, bb GB / cc GB avail含义字段含义xPG 总数y处于某特定状态如activeclean的 PG 数z已存储的数据量aa已使用的存储容量bb剩余可用存储容量ccPG 总存储容量注意Ceph 经常为一个 PG 同时报告多个状态例如activeclean、activecleanremapped、activecleanscrubbing等。容量信息已用aa、剩余bb、总量cc在以下场景中尤其重要集群正接近near full ratio接近满阈值或full ratio满阈值由于 CRUSH 配置错误数据未能在集群中均匀分布。PG ID 的构成PG ID 由池编号注意是编号而非池名加句点.加十六进制数组成。通过ceph osd lspools可查看池编号与池名的对应关系。例如第一个创建的池对应池编号1。完整的 PG ID 形式为{pool-num}.{pg-id}典型示例1.1701b查询 PG 的常用命令列出所有 PGceph pg dump以 JSON 格式输出并保存到文件ceph pg dump -o {filename} --formatjson查询特定 PG 的详细信息Ceph 以 JSON 格式输出ceph pg {poolnum}.{pg-id} query例如查询池1中 PG1701b的详情ceph pg 1.1701b query。常见 PG 状态详解Ceph 在源码 src/osd/osd_types.h 中以位掩码定义了各 PG 状态如PG_STATE_ACTIVE、PG_STATE_CLEAN、PG_STATE_DEGRADED、PG_STATE_RECOVERING、PG_STATE_BACKFILL_WAIT、PG_STATE_BACKFILLING、PG_STATE_INCOMPLETE、PG_STATE_STALE、PG_STATE_REMAPPED多个状态位可同时置位这正是activeclean、activecleanremapped这类组合状态名称的由来。以下按 PG 生命周期逐个讲解。Creating创建中创建池时即创建 PG创建池的命令会指定该池的 PG 总数池创建后所有 PG 一并创建。创建期间 Ceph 会回显creating。PG 创建完成后其 Acting Set 中的 OSD 开始 PeeringPeering 完成后PG 状态应变为activeclean此时 Ceph 客户端开始向该 PG 写入数据。/-----------\ /-----------\ /-----------\ | Creating |------| Peering |------| Active | \-----------/ \-----------/ \-----------/Peering对等中PG 对等时存储其数据副本的 OSD 就 PG 内的数据与元数据收敛到一致状态。对等完成后这些 OSD 对该 PG 的状态达成共识。但需要注意对等过程完成并不意味着每个副本都已拥有最新内容。关于**权威历史Authoritative History**的机制说明在 Acting Set 中每个 OSD 都持久化了某次写操作之前Ceph 不会向客户端确认acknowledge该写操作。这保证了自上次成功对等以来Acting Set 中至少有一个成员保留着每一次已确认写操作的记录。凭借准确的已确认写操作记录Ceph 可以构造出该 PG 的新的权威历史——即一整套完整且全序的操作序列按序执行即可让某个 OSD 上的 PG 副本追上最新状态。Active活跃Ceph 完成对等后PG 应变为active。active状态意味着该 PG 中的数据在 primary 和副本 OSD 上通常可进行读写操作。Clean干净PG 处于clean状态时所有持有其数据与元数据的 OSD 都已成功对等且不存在 stray游离副本Ceph 已将该 PG 中的所有对象复制了正确次数。Degraded降级客户端向 primary OSD 写入对象后primary 负责把副本写到副本 OSD。在 primary 将对象写入存储后PG 会保持degraded状态直到 primary 收到副本 OSD 确认成功创建副本对象的回执。PG 可能处于activedegraded的原因OSD 即使尚未持有 PG 的全部对象也可以保持active。若某 OSDdownCeph 会将该 OSD 上每个 PG 标记为degraded该 OSD 恢复上线后PG 必须重新对等。但只要 PG 是active的客户端仍可向其写入新对象。down到out的自动转换若 OSDdown且degraded状态持续存在Ceph 可能将该down的 OSD 标记为out并把数据从它 remap 到其他 OSD。从标记down到标记out的时间由mon_osd_down_out_interval决定默认600 秒10 分钟。在源码 src/common/options/mon.yaml.in 中该参数定义明确为 mark any OSD out that has been down for this long (seconds)默认值10_min服务对象为 monitor。与之配合的还有mon_osd_down_out_subtree_limit默认rack即整个机架子树全挂时不自动标记 out与mon_osd_min_up_ratioup 比例过低时不自动标记 out这些防御性参数可避免级联故障时 OSD 被批量踢出集群。另一种进入degraded的途径PG 中存在一个或多个 Ceph 期望找到却找不到的对象unfound objects。虽然无法读写这些 unfound 对象但degradedPG 中的其他对象仍可正常访问。Recovering恢复中Ceph 天生为容错而设计硬件与其他服务器问题被视作常态。当 OSDdown时其内容可能落后于 PG 中其他副本的当前状态OSD 回到up后必须将 PG 内容更新到当前状态此期间 OSD 可能处于recovering状态。恢复并非总是轻而易举一次硬件故障可能引发多个 OSD 的级联故障。例如某个机架或机柜的交换机故障可能导致多台主机上的 OSD 同时落后于集群当前状态。此类场景下只有每个 OSD 都在故障解除后恢复整体恢复才可能完成。Ceph 提供多个参数来权衡处理新服务请求与恢复数据对象、把 PG 恢复到最新状态之间的资源竞争参数作用默认值源码依据osd_recovery_delay_start允许 OSD 重启、重新对等、处理部分 replay 请求后再启动恢复0osd.yaml.inosd_recovery_thread_timeout确定恢复线程的超时时长多个 OSD 可能以交错速率失败、重启、重新对等文档描述值osd_recovery_max_active限制 OSD 同时处理的恢复请求数防止 OSD 无法继续服务0非零才生效实际按磁盘类型取 hdd/ssd 值osd.yaml.inosd_recovery_max_active_hdd机械盘rotational主设备 OSD 的同时恢复请求数3osd.yaml.inosd_recovery_max_active_ssdSSD非旋转介质主设备 OSD 的同时恢复请求数10osd.yaml.inosd_recovery_max_chunk限制恢复数据块的大小防止网络拥塞size 类型osd.yaml.in其中osd_recovery_max_active默认值为0此时实际生效的是按主设备类型区分的osd_recovery_max_active_hdd/osd_recovery_max_active_ssd只有显式设为非零值时才覆盖二者。另外注意mClock 调度器激活时这些恢复/背填上限通常不可修改详见下文 Backfilling 一节的说明。Backfilling背填新 OSD 加入集群时CRUSH 会把集群中已有 OSD 上的 PG 重新分配给新 OSD。若强制新 OSD 立即接受被重新分配的 PG会给它带来过大负载backfill背填允许该过程在后台进行。背填完成后新 OSD 一旦就绪即可开始服务请求。背填期间可能看到的状态backfill_wait背填操作已排队但尚未开始backfilling背填操作正在进行中backfill_toofull请求了背填但因存储容量不足无法完成。该状态可能是暂时性的——随着 PG 被搬移腾出空间条件变化后即可继续这与backfill_wait类似当 PG 无法被背填时可能被视为incomplete不完整。Ceph 提供多个参数管理 PG 重新分配尤其是新 OSD带来的负载尖峰参数作用默认值源码依据osd_max_backfills指定单个 OSD 并发背填进/出的最大数量1osd.yaml.inbackfill_full_ratioOSD 接近 full ratio 时拒绝背填请求90%可用ceph osd set-backfillfull-ratio修改osd_backfill_retry_interval背填被拒绝后的重试间隔30秒osd.yaml.inosd_backfill_scan_min每次背填扫描的最小对象数64osd.yaml.inosd_backfill_scan_max每次背填扫描的最大对象数512osd.yaml.in关于osd_max_backfills与 mClock若 mClock 调度器 处于激活状态默认情况下不能修改osd_max_backfills同理还有osd_recovery_max_active_hdd与osd_recovery_max_active_ssd除非设置osd_mclock_override_recovery_settings true——源码 osd.yaml.in 明确记录了这一限制。mClock 下的背填调优参见 mClock recovery/backfill 选项。backfill_full_ratio命令存在于ceph osd set-backfillfull-ratio在 src/mon/MonCommands.h 中定义参数类型为CephFloat取值范围0.0|1.0语义为 set usage ratio at which OSDs are marked too full to backfill。Remapped重映射当服务某 PG 的 Acting Set 发生变化时数据从旧 Acting Set 迁移到新 Acting Set。由于新 primary OSD 开始服务请求可能需要时间旧 primary 可能被要求继续服务请求直到 PG 数据迁移完成。数据迁移完成后映射使用新 Acting Set 的 primary OSD。Stale陈旧Ceph 使用心跳heartbeat确保主机与守护进程在运行但ceph-osd守护进程可能进入stuck卡住状态无法及时上报统计信息例如发生临时网络故障。默认情况下OSD 守护进程每0.5 秒上报一次 PG、up-through、boot 与失败统计频率高于心跳阈值定义的报告间隔。若 PG 的 Acting Set 中 primary OSD 未能向 monitor 上报或其它 OSD 已上报该 primarydownmonitor 就会将该 PG 标记为stale。集群启动时看到stale状态很常见直到对等过程完成。但集群运行一段时间后仍出现stale则说明这些 PG 的 primary OSD 已down或未向 monitor 上报 PG 统计信息。识别问题 PGstuck 状态排查如前所述PG 状态不是activeclean并不代表一定有问题。但当 PG卡住stuck时可能意味着 Ceph 无法执行自我修复。三种 stuck 状态状态含义Unclean不干净PG 包含未按期望次数复制的对象。正常情况下可假定这些 PG 正在恢复recovering。Inactive不活跃PG 无法处理读写因为它在等待持有最新数据的 OSD 回到up。Stale陈旧PG 处于未知状态因为托管它们的 OSD 在特定时间段由mon_osd_report_timeout决定内未向 monitor 集群上报。mon_osd_report_timeout在源码 src/common/options/global.yaml.in 中的语义是OSD 未向 mons 上报则被标记为 down 的宽限时间秒默认值15_min15 分钟服务对象为 monitor。识别卡住的 PGceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]更多背景参见 Placement Group 子系统ceph pg命令总览。stuck PG 的完整排查流程参见 failures-pg-stuck。定位对象位置从对象名到 PG 再到 OSD要在 Ceph Object Store 中存储对象数据Ceph 客户端必须设定对象名object name指定一个池pool。Ceph 客户端获取最新集群地图后CRUSH 算法先计算如何把对象映射到 PG再计算如何把 PG 动态分配到 OSD。仅凭对象名与池名即可定位对象ceph osd map {poolname} {object-name} [namespace]练习定位一个对象第一步用rados put创建对象指定对象名、测试文件路径与池名rados put {object-name} {file-path} --pooldata rados put test-object-1 testfile.txt --pooldata验证对象已存入 Ceph Object Storerados -p data ls定位对象的存放位置ceph osd map {pool-name} {object-name} ceph osd map data test-object-1Ceph 应输出对象位置例如osdmap e537 pool data (1) object test-object-1 - pg 1.d1743484 (1.4) - up ([0,1], p0) acting ([0,1], p0)该输出依次给出osdmap epoche537、池名与池编号data (1)、对象名、对象所属的 PG完整 PG ID1.d1743484与短形式1.4、以及该 PG 的 Up Set[0,1]primary 为p0与 Acting Set[0,1]primary 为p0。清理测试对象rados rm test-object-1 --pooldata随着集群演进对象位置可能动态变化。Ceph 动态再平衡的一大好处就是省去了人工执行迁移的负担相关机制详见 架构文档。这种对象 → PG → OSD的两级间接映射也正是数据放置data placement的核心设计数据不直接绑定到特定 OSD因此故障时只需在 PG 与底层 OSD 层面追踪问题即可。监控实战小结把整套监控动作串成一条排查主线看全局ceph -s/ceph health/ceph -w确认是否为HEALTH_OK之外的预期状态查 OSDceph osd stat对比in与up数量ceph osd tree定位down的 OSD必要时sudo systemctl start ceph-osdN查 PGceph pg stat查看状态分布ceph pg dump/ceph pg dump -o {file} --formatjson导出明细ceph pg {poolnum}.{pg-id} query深查单个 PG找卡住的 PGceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]对照mon_osd_report_timeout默认 15 分钟与mon_osd_down_out_interval默认 600 秒等参数判断是正在自我恢复还是需要人工介入定位对象ceph osd map {poolname} {object-name}把对象、PG、OSD 三层映射关系串起来结合 troubleshooting-osd 与 troubleshooting-pg 进行根因分析。理解 OSD 状态四象限、PG 生命周期状态机以及 Acting Set / Up Set 的含义是读懂上述所有命令输出的基础。Ceph 是自修复系统多数非HEALTH OK状态会随对等、恢复、背填的完成而自行消退只有当 PG 长期 stuck、副本持续 degraded 或容量达到阈值时才需要依据本文的参数调优与排查路径进行人工干预。赞分享存储分布式文件系统对象存储后端高可用【免费下载链接】cephCeph is a distributed object, block, and file storage platform项目地址https://gitcode.com/gh_mirrors/ce/ceph点击查看免费下载相关推荐Ceph RADOS 故障排查完全指南从动态日志调试到 Monitor/OSD/PG 深度排障与性能剖析Ceph RADOS 故障排查完全指南从动态日志调试到 Monitor/OSD/PG 深度排障与性能剖析 本文基于 Ceph 官方 RADOS 故障排查文档体存储分布式文件系统对象存储后端高可用Ceph 集群运维实战指南启动、健康监控、数据放置与故障排查Ceph 集群运维实战指南启动、健康监控、数据放置与故障排查 Ceph 是分布式对象、块和文件存储平台其集群运维工作分布在四个层次以 systemd 启停存储分布式文件系统对象存储后端高可用Rook Ceph 在 OpenShift 上的存储监控启用与故障排查指南Rook Ceph 在 OpenShift 上的存储监控启用与故障排查指南 OpenShift 控制台Storage Dashboard依赖 OpenShi云原生存储容器编排运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考