4.18 发行注记

DR 仪表板中的 VolSync 报告 operator 降级

在以前的版本中，Red Hat Advanced Cluster Management for Kubernetes (RHACM) 2.13 在受管集群上部署了 Volsync Operator，而无需创建 ClusterServiceVersion (CSV)自定义资源(CR)。因此，OpenShift 没有为 Volsync 生成 csv_succeeded 指标，因此 ODF-DR 仪表板不会显示 Volsync operator 的健康状况。

在这个版本中，对于 Volsync，csv_succeeded 指标被 kube_running_pod_ready 替换。因此，RHACM 指标白名单 ConfigMap 已更新，ODF-DR 仪表板能够有效地监控 Volsync operator 的健康状况。

(DFBUGS-1293)

使用 Volsync 的复制需要在同步 PVC 前挂载 PVC

在以前的版本中，没有挂载的 PVC 不会被同步到二级集群。

在这个版本中，ODF-DR 会同步 PVC，即使它不是 PVCLabelSelector 的一部分。

(DFBUGS-580)

尝试删除不存在的存储桶类或 OBC 会导致 MCG CLI 出现错误

在以前的版本中，尝试使用 MCG CLI 删除不存在的存储桶类或对象存储桶声明(OBC)不会出现错误。

在这个版本中，在 CLI 删除 bucketclasses 和 OBCs 时的错误消息会被改进。

(DFBUGS-201)

在 s3 get 操作中观察到 502 bad Gateway: noobaa is throwing error at 'MapClient.read_chunks: chunk ERROR Error: has chunk errors chunk

在以前的版本中，因为 MCG 中的竞争条件被取消上传和 dedup 流发现匹配项，所以对象已损坏。上述部分将被标记为重复，然后取消并回收，阻止第二个 duped 部分指向一个不再有效的重新声明数据。

在这个版本中，避免使用尚未标记为完成上传的块，并在完成后添加一个时间缓冲以确保块处于活动状态，并可以去掉。

(DFBUGS-216)

命名空间存储处于被拒绝状态

在以前的版本中，当 MCG 尝试验证目标存储桶的访问和存在时，在监控 NSStore 的过程中，即使它们应该被忽略，也不会忽略某些错误。

在这个版本中，当对象不存在时，阻止 read-object_md 问题报告。

(DFBUGS-700)

更新存储桶配额始终会导致 1PB 配额的限制

在以前的版本中，MCG 存储桶配额会导致 1PB 配额限制，而不考虑所需的值。

在这个版本中，存储桶配额限制会设置正确的值。

(DFBUGS-1173)

通过 boto3 >= 1.36.0 使用 PutObject 会导致 InvalidDigest 错误

在以前的版本中，带有使用升级 AWS SDK 或 CLI 的客户端的 PUT 请求会导致错误，因为 AWS SDK 或 CLI 更改了默认的 S3 客户端行为，以始终为支持它的操作计算校验和。

在这个版本中，通过更改的行为允许来自 S3 客户端的 PUT 请求。

(DFBUGS-1513)

设置 panic_on_warn 时，ceph_fill_file_size 中的内核 ceph fs module panicked

在以前的版本中，因为存在特定的硬生成 CephFS 场景，会出现带有备注的同步的内核 panic: panic-on_warn_set。

在这个版本中，RHEL 内核已被修复，因此不再发生特定的 CephFS 场景。

(DFBUGS-551)

ceph-csi-controller-manager pods OOMKilled

在以前的版本中，ceph-csi-controller-manager pod 是 OOMKilled，因为这些 pod 会在安装 OpenShift Data Foundation 时尝试缓存集群中的所有 configmap。

在这个版本中，缓存只适用于运行 ceph-csi-controller-manager pod 的命名空间。因此，pod 的内存用量是 stable，pod 不会被 OOMKilled。

(DFBUGS-938)

首选 在与放置反关联性相同的节点上调度 rook-ceph-mds pod，则不需要

在以前的版本中，活跃 MDS 守护进程的 MDS pod 可以调度到同一故障域中，因为 MDS pod 具有 首选 pod 反关联性。

在这个版本中，对于 activeMDS = 1，会应用所需的 反关联性。对于 activeMDS > 1，首选 反关联性保留。因此，当 active MDS = 1 时，活跃守护进程的两个 MDS pod 需要 反关联性，确保它们没有调度到同一故障域中，并且当 activeMDS >1 时，反关联性将 首选，并且可以在同一节点上调度 MDS。

(DFBUGS-1509)

工具提示在其他组件后面呈现

在以前的版本中，当将图形或图表悬停在图形或图表后，工具提示会被隐藏在图形或图表后面，且值不可见（在仪表板中）。这是因为 PatternFly v5 库问题。

在这个版本中，PatternFly 更新至次版本，因此工具提示会明确可见。

(DFBUGS-156)

后备存储详情显示不正确的供应商

在以前的版本中，因为供应商名称不正确的映射，TapStore 详情页面会显示不正确的供应商。

在这个版本中，UI 逻辑已被更新，以正确显示供应商名称。

(DFBUGS-353)

Popup 无法在规则上警报的错误消息

在以前的版本中，可以在不通知的情况下，使用不同命名空间中的相同名称创建 OBC，这会导致潜在的冲突或意外行为。这是因为用户界面没有在命名空间间跟踪对象存储桶声明(OBC)。这允许重复的 OBC 名称没有正确的警告。

在这个版本中，验证逻辑已被更新，以便在尝试使用重复名称创建 OBC 时正确检查和通知。如果存在具有相同名称的 OBC，则会显示一个清晰的警告，防止混淆并确保行为正确。

当点击 StorageClass 创建过程中点击"Enable Encryption"复选框时，会显示一个 404: Not Found 信息。

在以前的版本中，在新 StorageClass 创建过程中使用"Enable Encryption"复选框启用加密时，会简要显示 "404: Not Found" 信息。

在这个版本中，导致这个问题的条件已被修复。因此，"404: Not Found"，在一些加载状态后直接显示配置表单。

DFBUGS-489

现有警告警报 "Inconsistent data on target cluster" 不会中断

在以前的版本中，当为 failover/relocate 操作选择了不正确的目标集群时，现有警告警报 "Inconsistent data on target cluster" 不会消失。

在这个版本中，在更改订阅应用程序的目标集群时，会正确刷新警告警报。因此，当为发现的应用程序触发故障转移/重新定位时，警报不再会被不必要地保留。

(DFBUGS-866)

rook-ceph-osd-prepare-ocs-deviceset pod 生成重复指标

在以前的版本中，因为 OSD 准备 pod 中的重复容限，所以从 kube-state-metrics 引发警报。

在这个版本中，完成的 OSD 准备带有重复容限的 pod 会被删除。因此，不再会引发与升级相关的重复警报。

(DFBUGS-839)

Prometheus 规则评估错误

在以前的版本中，不会触发大量 PrometheusRuleFailures 错误日志和受影响的警报，因为许多包含指标 ceph_disk_occupation 的警报或规则查询有错误或无效的标签。

在这个版本中，错误的标签已被修正，受影响的警报的查询已被更新。因此，prometheus 规则评估正确，所有警报都已被成功部署。

(DFBUGS-789)

当 MDS 使用量很高时，警报 "CephMdsCPUUsageHighNeedsVerticalScaling" 不会触发

在以前的版本中，ocs-operator 无法读取或部署不正确的规则文件，与此文件关联的警报不可见。这是因为 PrometheusRule 文件 prometheus-ocs-rule.yaml 错误地缩进。

在这个版本中，缩进已被修正，因此 PrometheusRule 文件已被成功部署。

(DFBUGS-951)

Regional-DR 使用多路径设备或分区磁盘从 v4.17 升级到 v4.18 失败

由于 Ceph 已知问题，带有多路径设备或分区磁盘的 Region-DR 环境不应从 v4.17 升级到 v4.18。这个问题将在 4.18 z-streams 或以后的发行版本中解决。

(DFBUGS-1801)

从 v4.17.z 升级到 v4.18 后，灾难恢复会被错误配置

当 ODF Multicluster Orchestrator 和 Openshift DR Hub Operator 从 4.17.z 升级到 4.18 时，一些灾难恢复资源会在内部模式中错误配置。这会影响使用 ocs-storagecluster-ceph-rbd 和 ocs-storagecluster-ceph-rbd-virtualization StorageClasses 进行工作负载的灾难恢复。

要解决这个问题，请按照本 知识库文章 中的说明操作。

(DFBUGS-1804)

当集群处于扩展模式时，Ceph df 会报告一个无效的 AVAIL 值

当 Red Hat Ceph Storage 集群的 crush 规则具有多个"take"步骤时，ceph df 报告显示该映射的最大可用大小。这个问题将在即将推出的版本中解决。

(DFBUGS-1748)

这两个 DRPC 都保护在同一命名空间中创建的所有持久性卷声明

托管多个灾难恢复(DR)保护工作负载的命名空间，保护 hub 集群上每个 DRPlacementControl 资源的命名空间，该命名空间不根据 spec.pvcSelector 字段在工作负载上指定并隔离 PVC。

这会导致 PVC 与多个工作负载的 DRPlacementControl spec.pvcSelector 匹配。或者，如果所有工作负载都缺少选择器，复制管理可能会多次管理每个 PVC，并根据单独的 DRPlacementControl 操作造成数据崩溃或无效操作。

临时解决方案：标签 PVC 属于唯一工作负载，并使用所选标签作为 DRPlacementControl spec.pvcSelector，以忽略哪个 DRPlacementControl 保护和管理命名空间中的哪些 PVC 子集。无法使用用户界面为 DRPlacementControl 指定 spec.pvcSelector 字段，因此必须使用命令行删除并创建此类应用程序的 DRPlacementControl。

结果： PVC 不再由多个 DRPlacementControl 资源管理，不会造成任何操作和数据不一致。

(DFBUGS-1749)

MongoDB pod 处于 CrashLoopBackoff，因为的权限错误读取 cephrbd 卷中的数据

跨不同受管集群的 OpenShift 项目具有不同的安全性上下文约束 (SCC)，这在指定的 UID 范围和/或 FSGroups 中有所不同。这会导致某些工作负载 pod 和容器无法在这些项目中启动后故障转移或重新定位操作，因为日志中的文件系统访问错误。

临时解决方案：确保在所有带有同一项目级别的 SCC 标签的受管集群中创建工作负载项目，以便在通过或重新定位失败时使用相同的文件系统上下文。Pod 不再对文件系统相关的访问错误失败失败。

(DFBUGS-1750)

灾难恢复工作负载在删除时会卡住

当从集群中删除工作负载时，对应的 pod 可能无法与 FailedKillPod 等事件终止。这可能会导致垃圾收集依赖的 DR 资源（如 PVC、VolumeReplication 和 VolumeReplicationGroup）的延迟或失败。它还可防止以后将相同的工作负载部署到集群中，因为过时的资源还没有垃圾回收。

临时解决方案：重启正在运行 pod 的 worker 节点，并处于终止状态。这会导致 pod 终止以及随后相关的 DR API 资源被收集垃圾回收。

(DFBUGS-325)

基于区域 DR CephFS 的应用故障转移显示有关订阅的警告

应用程序通过或重新定位失败后，hub 订阅会显示错误声明"Some resources failed to deploy.。使用 View status YAML 链接来查看详情"。这是因为，使用 CephFS 作为后备存储置备程序的应用持久性卷声明(PVC)，使用 Red Hat Advanced Cluster Management for Kubernetes (RHACM)订阅进行部署，并且具有 DR 保护由对应的 DR 控制器所有。

临时解决方案：无法调整订阅状态中的错误。但是，可以检查无法部署的订阅资源，以确保它们是 PVC。这样可确保其他资源没有问题。如果无法部署的订阅中的唯一资源是 DR 保护的资源，则错误可以被忽略。

(DFBUGS-253)

禁用 PeerReady 标志可防止将操作改为 Failover

DR 控制器根据需要执行完全协调。当集群无法访问时，DR 控制器会执行完整性检查。如果工作负载已重新定位，则此 sanity 检查会导致与工作负载关联的 PeerReady 标志被禁用，因为集群离线，sanity 检查不会完成。因此，禁用 PeerReady 标志可防止您将操作改为 Failover。

临时解决方案：即使禁用了 PeerReady 标志，使用命令行界面将 DR 操作改为 Failover。

(DFBUGS-665)

当连接在扩展集群的两个数据中心之间丢失连接时，Ceph 变得无法访问，并且 IO 暂停

当两个数据中心相互丢失但仍然连接到 Arbiter 节点时，在选择逻辑中存在一个缺陷，这会导致监视器之间有无限选举。因此，监控器无法选举领导，Ceph 集群将不可用。另外，IO 在连接丢失过程中暂停。

临时解决方案：通过关闭区节点来关闭任何一个数据区的监控器。另外，您可以重置存活 mon pod 的连接分数。

因此，监控器可以形成仲裁，Ceph 会再次可用，IOs 恢复。

(DFBUGS-425)

在从替换集群中使用过时的 Ceph 池 ID 时，RBD 应用无法分配

对于在创建新对等集群之前创建的应用，无法挂载 RBD PVC，因为当替换对等集群时，无法更新 CSI configmap 中的 CephBlockPoolID 的映射。

临时解决方案：在未替换的对等集群中，将 rook-ceph-csi-mapping-config configmap 更新为 cephBlockPoolID 的映射。这将启用为应用挂载 RBD PVC。

(DFBUGS-527)

有关 lastGroupSyncTime 的信息会在 hub 恢复后丢失，这些工作负载在不可用受管集群上是主的

以前失败的应用程序不会报告 lastGroupSyncTime，从而导致警报 VolumeSynchronizationDelay 触发。这是因为当 ACM hub 和作为 DRPolicy 一部分的受管集群不可用时，从备份中重建新的 ACM hub 集群。

临时解决方案：如果工作负载失败的受管集群不可用，您仍可以切换到一个存活的受管集群。

(DFBUGS-376)

MCO operator 协调 veleroNamespaceSecretKeyRef 和 CACertificates 字段

当 OpenShift Data Foundation Operator 升级时，Ramen 配置中的 s3StoreProfiles 下的 CACertificates 和 veleroNamespaceSecretKeyRef 字段将会丢失。

临时解决方案：如果 Ramen 配置具有 CACertificates 和 veleroNamespaceSecretKeyRef 字段的自定义值，则在执行升级后如何设置这些自定义值。

(DFBUGS-440)

升级后 token-exchange-agent pod 的不稳定

受管集群中的 token-exchange-agent pod 不稳定，因为旧的部署资源不会被正确清理。这可能导致应用程序故障切换操作失败。

临时解决方案： 在升级到 ODF 4.17.0 后，请参阅知识库文章 "token-exchange-agent" pod is unstable。

结果：如果遵循这个临时解决方案，"token-exchange-agent" pod 是 stabilized，故障转移操作可以正常工作。

(DFBUGS-561)

VirtualMachines.kubevirt.io 资源因为重新定位中的 mac 分配失败而无法恢复

当虚拟机重新定位到首选集群时，由于 mac 地址不可用，它可能无法完成重新定位。如果虚拟机在故障转移集群时没有完全清理在首选集群中，会出现这种情况。

在重新定位工作负载前，请确保工作负载从首选集群完全删除。

(BZ#2295404)

当还没有创建 ReplicationDestination 资源时，故障转移过程会失败

如果用户在 LastGroupSyncTime 更新前启动故障转移，故障转移过程可能会失败。此失败由一条错误消息指示 ReplicationDestination 不存在。

临时解决方案：

编辑 hub 集群上 VRG 的 ManifestWork。

从清单中删除以下部分：

/spec/workload/manifests/0/spec/volsync

保存更改。

正确应用此临时解决方案可确保 VRG 跳过使用 ReplicationDestination 资源恢复 PVC。如果 PVC 已存在，应用程序会原样使用。如果 PVC 不存在，则会创建新的 PVC。

(DFBUGS-632)

在向集群添加容量后，Ceph 处于警告状态

在设备替换或添加容量过程后，观察到 Ceph 处于 HEALTH_WARN 状态，并带有 mon 报告缓慢的 ops。但是，对集群的可用性没有影响。

(DFBUGS-1273)

OSD pod 在添加容量过程中重启

通过向集群添加容量，OSD pod 会在执行集群扩展后重启。但是，除了 pod 重启外，不会对集群造成影响。

(DFBUGS-1426)

由于角色的信任策略中缺少条目，NooBaa Core 无法假设角色具有 Web 身份的角色

对于使用 AWS 安全令牌服务(STS)的 AWS 上的 OpenShift Data Foundation 部署，您需要在 noobaa-core 帐户的信任策略中添加另一个条目。这是因为在 OpenShift Data Foundation 4.17 发行版本中，服务帐户已从 noobaa 改为 noobaa-core。

有关在 noobaa-core 帐户的信任策略中添加条目的说明，请参阅将 Red Hat OpenShift Data Foundation 4.16 更新至 4.17 的先决条件部分中的最终漏洞。

(DFBUGS-172)

升级到 OpenShift Data Foundation 4.17 会导致 noobaa-db pod CrashLoopBackOff 状态

当 PostgreSQL 升级在 Multicloud Object Gateway 中因为 PostgresSQL 版本 15 开始，从 OpenShift Data Foundation 4.15 升级到 OpenShift Data Foundation 4.17 时会失败。如果有 PostgreSQL 升级失败，NooBaa-db-pg-0 pod 无法启动。

临时解决方案：请参阅 OpenShift Data Foundation 4.17 中的知识库文章 Recover NooBaa 的 PostgreSQL 升级失败。

(DFBUGS-1751)

CephFS 上扩展集群的性能不佳

具有许多小元数据操作的工作负载可能会因为在多站点 Data Foundation 集群上放置元数据服务器(MDS)造成性能不佳。

(DFBUGS-1753)

SELinux 重新标记问题，带有大量文件

当将卷附加到 Red Hat OpenShift Container Platform 中的 pod 时，pod 有时无法启动或需要很长时间才能启动。这个行为是通用的，它绑定到 Kubelet 处理 SELinux 重新标记的方式。对于任何基于文件系统的卷，会发现这个问题。在 OpenShift Data Foundation 中，使用基于 CephFS 的卷和大量文件时会出现此问题。解决此问题的方法有多种。根据您的业务需求，您可以从知识库解决方案 https://access.redhat.com/solutions/6221251 中选择一个临时解决方案。

(Jira#3327)

自动扁平化快照无法正常工作

当有一个常见的父 RBD PVC 时，如果卷快照、恢复和删除快照是在超过 450 次的序列中执行的，则无法进行卷快照或克隆通用父 RBD PVC。

要解决这个问题，而不是按顺序执行卷快照、恢复和删除快照，您可以使用 PVC 克隆来完全避免这个问题。

如果您达到此问题，请联系客户支持来手动扁平化最终恢复的 PVC，以继续对常见父 PVC 进行卷快照或克隆。

(DFBUGS-1752)

在单一命名空间中部署多个工作负载时优化 DRPC 创建

当多个应用程序引用同一放置时，为任何应用程序启用 DR 会为引用放置的所有应用程序启用它。

如果在创建 DRPC 后创建了应用程序，则 DRPC 中的 PVC 标签选择器可能与更新的应用程序的标签不匹配。

临时解决方案： 在这种情况下，建议禁用 DR，并使用正确的标签选择器再次启用它。

(DFBUGS-120)

当 pod 处于 CLBO 状态时，增加 MDS 内存正在清除 CPU 值

当元数据服务器(MDS)内存在 MDS pod 处于崩溃循环时增加(CLBO)状态，删除了 MDS pod 的 CPU 请求和限值。因此，为 MDS 更改设置的 CPU 请求或限制。

临时解决方案：运行 oc patch 命令来调整 CPU 限值。

例如：

$ oc patch -n openshift-storage storagecluster ocs-storagecluster \
    --type merge \
    --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "3"},
    "requests": {"cpu": "3"}}}}}'

(DFBUGS-426)

在协调：Service "ocs-provider-server" 时出现错误无效：spec.ports[0].nodePort: Invalid value: 31659: provided port is allocated

在 OpenShift Data Foundation 4.18 中，ocs-oeprator 使用端口 31659 部署服务，这可能会与现有服务 nodePort 冲突。由于其它服务已经在使用中，则无法使用此端口。因此，在部署服务时，ocs-oeprator 始终出错。这会导致升级协调卡住。

临时解决方案：将 nodePort 替换为 ClusterIP 以避免冲突：

oc patch -nopenshift-storage storagecluster ocs-storagecluster --type merge -p '{"spec": {"providerAPIServerServiceType": "ClusterIP"}}'

(DFBUGS-1831)

在带有托管的 control plane (HCP)部署的 Red Hat OpenShift Service on AWS (ROSA)中，Prometheus -operator pod 缺少容限

由于在 ROSA HCP 部署上的 Red Hat OpenShift Data Foundation 过程中存在一个已知问题，在 Pod 创建后需要手动为 prometheus-operator 应用容限。要应用容限，请运行以下 patch 命令：

$ oc patch csv odf-prometheus-operator.v4.18.0-rhodf -n odf-storage --type=json -p='[{"op": "add", "path": "/spec/install/spec/deployments/0/spec/template/spec/tolerations", "value": [

{"key": "node.ocs.openshift.io/storage", "operator": "Equal", "value": "true", "effect": "NoSchedule" }
]}]'

(DFBUGS-1272)

odf-CLI 工具错误地标识过时的卷

因为过时的子卷识别工具中的问题，Stale 子卷 CLI 工具会错误地将有效的 CephFS 持久性卷声明(PVC)显示为 stale。因此，这个问题已修复了过时的子卷识别功能。

(DFBUGS-3778)