第 6 章 程序错误修复
本节论述了在这个 Red Hat Ceph Storage 发行版本中修复的用户有严重影响的错误。此外,部分还包括之前版本中发现的固定已知问题的描述。
6.1. Ceph Ansible 实用程序
/targets
URL 显示 Prometheus 作为 down
在以前的版本中,Prometheus 目标 URL 配置有 localhost
值。当目标状态被视为关闭时,localhost
值会导致 Prometheus 服务不侦听 localhost
地址。在这个版本中,Prometheus 配置文件被更新为使用目标 URL 值的 IP 地址。因此,Prometheus 目标状态会被正确报告。
Ceph-volume
可能会在 Ceph 部署中创建 OSD 时造成元数据崩溃
在以前的版本中,当 ceph-volume
发出 LVM 命令时,如创建卷组、逻辑卷、设置标签等时,在 Ceph 部署期间创建 OSD 时可能会导致元数据损坏。在此发行版本中,用户可以通过将主机上的 group
参数设置为 _vars/all.yml
文件中的 lvmetad
_disabledtrue
来禁用 lvmetad 服务,从而可以避免元数据崩溃。
ceph-ansible
中的 ceph-dashboard
角色强制将自签名证书的通用名称强制到 ceph-dashboard
在以前的版本中,当使用 ceph-ansible
生成的自签名证书时,它会强制将通用名称(CN)强制到 ceph-dashboard
,从而导致 Prometheus 等应用程序因为节点向客户端发送证书不匹配而出现错误。
在这个版本中,ceph-ansible
设置具有适当值的 CN,Prometheus 可以正常工作。
当 Ceph 容器并置时,滚动升级会失败
当 Ceph 监控器和 Ceph 对象网关守护进程与容器并启用了多站点 Ceph 对象网关时,roll _update.yml
Ansible playbook 会失败。此失败是由 radosgw-admin
命令造成的,因为 Ceph Monitor 容器在升级过程中停止,因此无法执行。在这个版本中,在升级过程中跳过 ceph-handler
角色内的多站点 Ceph 对象网关代码。因此,roll _update.yml
Ansible playbook 会成功运行。
在切换到容器化守护进程时,Ceph Monitor 仲裁检查会失败
switch-from-non-containerized-to-ceph-daemons.yml
Ansible playbook 中引入了一个回归程序错误。因为当前节点的主机名没有测试,所以 Ceph Monitor 仲裁检查导致 Ceph Monitor 仲裁检查失败。在这个版本中,当前 Ceph Monitor 节点的 ansible_hostname
事实会被正确使用。因此,Ceph Monitor 仲裁检查可以成功。
在升级失败时添加新 Ceph 对象网关实例
radosgw_frontend_port
选项没有考虑多个 Ceph 对象网关实例,并且为所有实例配置了端口 8080
。在这个版本中,每个 Ceph 对象网关实例增加了 radosgw_frontend_port
选项,允许您使用多个 Ceph 对象网关实例。
Ceph Ansible 删除任何套接字文件,并启用集群重新部署
在以前的版本中,*.asok 文件保留在清除 playbook 完成后,从而导致在重新部署集群时失败。在这个版本中,ceph-ansible
会移除任何可能存在的套接字文件,并可安全地重新部署集群。
添加了对容器化 Red Hat Ceph Storage 部署中的 tcmu-runner 进程的日志轮转的支持
在以前的版本中,当在容器中部署带有 iSCSI 的 Red Hat Ceph Storage 时,tcmu-runner 进程没有日志轮转,因此消耗容器中的所有空间。在这个版本中,日志轮转支持被添加到 tcmu-runner 进程中,日志文件会定期轮转,从而减少空间消耗。
对于混合了 FileStore OSD 和 BlueStore OSD 的 OSD 节点,FileStore 到 BlueStore 的迁移过程可能会失败
在以前的版本中,如果部署运行比 3.2 更早的 Red Hat Ceph Storage 版本,当没有将 osd_objectstore
在 group_vars
、host_vars
或 inventory
中明确设置时,部署会有 FileStore OSD。FileStore 是 Red Hat Ceph Storage 3.2 之前的默认设置。
将部署的存储集群升级到 Red Hat Ceph Storage 3.2 后,向现有 OSD 节点添加的新 OSD 将使用 BlueStore 后端,因为它成为新的默认值。这会导致在同一节点上混合使用 FileStore 和 BlueStore OSD。在某些情况下,FileStore OSD 可能会与 BlueStore OSD 共享日志或 DB 设备。在这种情况下,重新部署所有 OSD 会导致 ceph-volume
错误,原因是分区无法在 lvm batch
中传递,或者因为 GPT 标头。
在这个版本中,迁移混合了 FileStore 和 BlueStore 配置的 OSD 有两个选项:
-
在运行
filestore-to-bluestore.yml playbook
时,额外变量force_filestore_to_bluestore
被设为true
。此设置强制 playbook 自动迁移所有 OSD,甚至那些已使用 BlueStore 的 OSD。 -
运行
filestore-to-bluestore.yml
playbook,但不设置force_filestore_to_bluestore
(默认为false
)。这会导致 playbook 在混合了 FileStore 和 BlueStore OSD 的节点上自动跳过迁移。它将迁移仅具有 FileStore OSD 的节点。在 playbook 执行结束时,将显示一个报告来显示哪些节点被跳过。
在从 Red Hat Ceph Storage 3 升级到 4 之前,请手动检查跳过的每个节点,以确定迁移 OSD 的最佳方法。
(BZ#1875777)
可以在 Docker registry 密码中使用特殊字符
在以前的版本中,Docker registry 密码中设置的特殊字符不会被正确处理。在此发行版本中,如果在 Docker registry 中使用了特殊字符时,Ansible playbook 不会失败。现在 Docker registry 密码中可以使用特殊字符,Ansible playbook 可以按预期工作
ceph-volume
Ansible 模块报告有关逻辑卷和卷组的正确信息
在以前的版本中,当在带有基于 OSD 上的 Red Hat Enterprise Linux 8 容器的 Red Hat Enterprise Linux 7 主机中应用 ceph-volume lvm zap --destroy
命令时,lvm 缓存没有为主机刷新,仍然报告存在的逻辑卷和卷组。在这个版本中,ceph_volume
Ansible 模块会在主机上触发 命令,以确保刷新 lvm 缓存并报告有关逻辑卷和卷组的正确信息。
可以使用 journalctl
命令查看 Ceph 容器日志
在以前的版本中,在 journald 中不存在 Ceph 容器日志,因为 Podman 在以分离模式运行容器和 systemd 类型时,使用 Kubernetes 文件作为默认日志驱动程序。在这个版本中,Ceph 容器配置有 journald 日志驱动程序,其日志可通过 journalctl
命令访问。
Ceph Ansible 将文件和目录所有权值设置为 nobody:nobody
在以前的版本中,Ceph Ansible 将文件和目录所有权值设置为 root:root
。这会导致 alertmanager
和 prometheus
服务的权限问题。
在这个版本中,Ceph Ansible 将所有权设置为 nobody:nobody
。这消除了权限问题。