4.7. RADOS
在回填过程中解决进度和高 CPU 使用率
在以前的版本中,OSD 分片中带有最小索引的 worker 线程将返回到主 worker 循环,而不是等待项目从 mClock 队列中调度或直到通知为止。这会导致忙碌的循环和高 CPU 使用率。
在这个版本中,带有最小线程索引的 worker 线程会重新排序适当的锁,并等待通知,或直到 mClock 调度程序指示的时间周期 lapses。现在,worker 线程会等待项目从 mClock 队列调度或直到通知为止,然后返回到主 worker 循环,从而消除忙碌的循环并解决高 CPU 使用率问题。
当使用 STS 返回的临时凭证时,重命名大型对象不再会失败
在以前的版本中,由于重命名大型对象时的权限评估不正确,在使用 STS 返回的临时凭证时,重命名大型对象会失败。
在这个版本中,当 STS 返回的临时凭证用于重命名大型对象时,iam
策略会被正确评估。
小的写入延迟
在以前的版本中,Ceph 会在分配单元时延迟写入。当分配单元较大时,与 64 K 一样,没有小的写入有资格进行延迟。
在这个版本中,小的写入会延迟,因为它们在磁盘块上操作,即使大型分配单元被延迟。
在减少 monitor 数量后,Ceph Monitor 不再崩溃
在以前的版本中,当用户使用 ceph orch apply mon NUMBER
命令减少仲裁中的监控器数量时,cephadm
会在关闭前删除 monitor。这将触发断言,因为 Ceph 会假定 monitor 在移除 monitor 之前关闭。
在这个版本中,当 monitor 的当前等级大于或等于仲裁等级时,会添加健全检查来处理问题单。监控器不再存在于 monitor 映射中,因此其对等点不会 ping 此监控器,因为地址不再存在。因此,如果在关闭前删除了 monitor,则不会触发断言。
Ceph Manager 检查处理初始服务映射现在已被放宽
在以前的版本中,当升级集群时,Ceph Manager 会从之前活跃的 Ceph 管理器接收多个 service_map
版本。这会导致管理器守护进程崩溃,因为当新激活的管理器收到具有较高版本的映射时,代码中的检查不正确。
在这个版本中,Ceph Manager 中的检查处理初始服务映射被放大,以正确检查服务映射,在 Ceph 管理器故障切换过程中没有发生断言。
ceph --help
命令现在显示 yaml formatters 仅对 ceph orch
命令有效
在以前的版本中,在 ceph --help
命令中缺少规格,yaml formatter 选项对于任何 ceph 命令都有效,包括 ceph config dump
命令。
在这个版本中,ceph --help
命令的输出显示 yaml 格式ter 仅对 ceph orch
命令有效。
可以通过脱机和在线修剪删除 PG 日志条目损坏
在以前的版本中,在低级 PG 分割操作期间,PG 日志 dups 条目的修剪会无法被 PG 自动扩展器使用,超过人为 operator 的频率。使 dups 修剪导致 PG 日志的内存增长造成大量内存增长,因为 OSD 内存不足时会导致 OSD 崩溃。重启 OSD 不会解决这个问题,因为 PG 日志存储在磁盘上,并在启动时重新加载到 RAM。
在这个版本中,离线(使用 ceph-objectstore-tool
命令)和在线(带有 OSD)进行修剪可能会移除 PG Log 的损坏的 dups 条目,该条目会阻塞修建机制并导致内存增长。实施了调试功能,它将 dups 条目的数量输出到 OSD 的日志,以帮助调查未来。
添加 开始
消息来通知 scrub 或 deep-scrub 进程有 begun
在以前的版本中,用户无法决定为放置组(PG)启动清理过程,因为集群日志中缺少了 起始
信息。这使得无法计算清理或深度清理 PG 所需的时间。
在这个版本中,清理启动或
深度清理
启动消息,以通知用户清理或深度清理进程已开始 PG。
如果禁用了 PG-autoscaling,则 autoscale-status
命令不再显示 NEW PG_NUM
值
在以前的版本中,autoscale-status
命令会显示 NEW PG_NUM
值,即使没有启用 PG-autoscaling。这将建议 PG 自动缩放器将 NEW PG_NUM
值应用到池,而这不是这种情况。
在这个版本中,如果设置了 noautoscale
标志,则 autoscale-status
命令输出不会显示 NEW PG_NUM
值。
在升级集群后,用户可以删除克隆的对象
在以前的版本中,在将集群从 Red Hat Ceph Storage 4 升级到 Red Hat Ceph Storage 5 后,删除之前版本中创建的对象快照会离开克隆,且无法删除。这是因为 SnapMapper 键被错误地转换。
在这个版本中,更新了 SnapMapper 的传统对话,以匹配早期版本的 Ceph 中的新密钥格式和克隆对象,现在可以在升级后轻松删除。
ceph daemon heap stats
命令现在返回守护进程所需的用量详情
在以前的版本中,ceph daemon osd.x heap stats
命令会返回空输出,而不是 Ceph 守护进程的当前堆使用量。因此,用户被编译为使用 ceph tell heap stats
命令来获取所需的堆使用量。
在这个版本中,ceph daemon heap stats
命令返回 Ceph 守护进程的堆使用信息,类似于使用 ceph tell
命令的信息。
Prometheus 指标现在根据请求反映所有 Ceph Monitor 的正确 Ceph 版本
在以前的版本中,当监控器升级时,Prometheus 指标报告 Ceph Monitor 不匹配的 Ceph 版本。因此,需要重启活跃的 Ceph Manager 守护进程来解决这个问题。此外,Ceph 管理器通过 handle_mon_map
参数更新监控元数据,该参数会在从集群删除或添加监视器重启或
失败时触发。
mgr
在这个版本中,MON 现在明确向 mgr
发送带有 mon
元数据的元数据,而不依赖于使用 ceph mon metadata
获取 mon
元数据的元数据更新请求。
正确的副本集合用于 重新映射
放置组
在以前的版本中,对于 重新映射
放置组,在识别不存在的不匹配后,会查询错误的清理信息集合,从而导致清理过程失败。
在这个版本中,会查询正确的副本集合。
目标 rank_removed
不再处于 live_pinging
和 dead_pinging
状态
在以前的版本中,在某些情况下,Monitor Map 的 paxos_size
会在 monitor 的等级被改变前更新。例如,paxos_size
将从 5 到 4 减少,但 monitor 的最高等级仍然是 4,因此旧代码会跳过从 dead_pinging
状态中删除等级。这会导致目标等级保持在 dead_pinging
forever,这会导致 选择策略出现 strange
。
peer_tracker
分数: 3
在这个版本中,当 rank_removed == paxos_size ()
中从 live_pinging
和 dead_pinging
状态中清除目标 rank_removed
时,会添加一个问题单,等级不会处于其中任何一个状态。
在站点故障转移过程中 Ceph 监控器不会卡住
在以前的版本中,removed_ranks
变量不会丢弃 monitor 映射的每个更新的内容。因此,它将替换 2 个站点扩展集群中的监控器,并且通过其中一个站点故障导致连接分数(包括与分数关联的等级)不一致。
连接分数不一致会导致监控选择期间死锁,这会导致 Ceph 变得无响应。发生这种情况后,与连接分数关联的 monitor 等级无法更正其自身。
在这个版本中,每次 monitor 映射更新都会清除 removed_ranks
变量。监控器不再处于选举期间,在替换监控器并在站点出现故障时,Ceph 不再变得无响应。此外,也可以使用 ceph 守护进程 mon.NAME connection scores reset
命令手动强制连接分数来更正其自身。
用户现在可以将副本大小设置为 1
在以前的版本中,用户无法将 池大小
设置为 1
。check_pg_num
() 函数会错误地计算池的投射放置组数量,从而导致出现 inflow。由于 false 结果,它会显示 pg_num
大于最大限制。
在这个版本中,最近的 check_pg_num
() 函数编辑已被恢复,计算现在可以正常工作,而用户现在可以将副本大小设置为 1
。
如果在集群升级后没有设置 require-osd-release
标志,Ceph 集群会发出警告。
在以前的版本中,在代码重构过程中意外删除升级后,检测 require-osd-release
标记的代码逻辑。由于升级后 ceph -s
输出中没有引发警告,在对集群进行改变时没有将标志设置为适当的版本会导致出现问题,如放置组 (PG) 一直处于某些状态,消耗大量 Ceph 进程内存,请求变慢等问题。
在这个版本中,如果在集群升级后没有设置 require-osd-release
标志,Ceph 集群会发出警告。