4.12 发行注记

Red Hat OpenShift Data Foundation 4.12

功能增强、已知问题和其它重要发行信息的发行注记。

Red Hat Storage Documentation Team

摘要

本发行注记介绍了 Red Hat OpenShift Data Foundation 4.12 的新功能、功能增强、重要的技术更改,以及所有已知问题。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。请告诉我们如何让它更好。提供反馈:

  • 关于特定内容的简单评论:

    1. 请确定您使用 Multi-page HTML 格式查看文档。另外,确定 Feedback 按钮出现在文档页的右上方。
    2. 用鼠标指针高亮显示您想评论的文本部分。
    3. 点在高亮文本上弹出的 Add Feedback
    4. 按照显示的步骤操作。
  • 要提交更复杂的反馈,请创建一个 Bugzilla ticket:

    1. 进入 Bugzilla 网站。
    2. Component 部分中,选择 文档
    3. Description 中输入您要提供的信息。包括文档相关部分的链接。
    4. Submit Bug

第 1 章 概述

Red Hat OpenShift Data Foundation 是为容器环境优化的软件定义型存储。它在 OpenShift Container Platform 上作为操作器运行,为容器提供高度集成和简化的持久性存储管理。

Red Hat OpenShift Data Foundation 集成到最新的 Red Hat OpenShift Container Platform 中,用于解决平台服务、应用程序可移植性和持久性挑战。它为下一代云原生应用程序提供了高度可扩展的后端,它基于包括 Red Hat Ceph Storage、Rook.io Operator 和 NooBaa 的多云对象网关技术。OpenShift Data Foundation 还支持单节点 OpenShift 集群的逻辑卷管理器存储。如需更多信息,请参阅单一节点 OpenShift 集群的逻辑卷管理器存储正式发行

Red Hat OpenShift Data Foundation 提供了一个可信的企业级应用程序开发环境,它以多种方式简化并增强应用程序生命周期的用户体验:

  • 为数据库提供块存储。
  • 用于持续集成、消息传递和数据聚合的共享存储。
  • 用于云环境开发、存档、备份和媒体存储的对象存储。
  • 可适用于以指数级增长的应用程序和数据。
  • 以更快的速度附加和分离持久性卷。
  • 跨多个数据中心或可用区扩展集群。
  • 建立全面的应用程序容器 registry。
  • 支持下一代 OpenShift 工作负载,如数据分析、智能 Intelligence、机器学习、经济学和物联网(IoT)。
  • 动态置备应用程序容器,以及数据服务卷和容器,以及额外的 OpenShift Container Platform 节点、Elastic Block Store(EBS)卷和其他基础架构服务。

1.1. 关于此版本

Red Hat OpenShift Data Foundation 4.12 (RHBA-2023:0550RHBA-2023:0551) 现已可用。OpenShift Data Foundation 4.12 的新功能、已知的问题包括在此文档中。

Red Hat OpenShift Data Foundation 4.12 在 Red Hat OpenShift Container Platform 版本 4.12 上被支持。如需更多信息,请参阅 Red Hat OpenShift Data Foundation Supportability and Interoperability Checker

对于 Red Hat OpenShift Data Foundation 生命周期信息,请参阅 Red Hat OpenShift Container Platform 生命周期政策中的分层和依赖产品生命周期部分。

第 2 章 新功能

本节介绍 Red Hat OpenShift Data Foundation 4.12 中引入的新功能。

2.1. Metropolitan 灾难恢复(Metro-DR)解决方案正式发布

Red Hat Advanced Cluster Management for Kubernetes 2.7 的 Metro-DR 功能现在包括在 Red Hat OpenShift Data Foundation 版本 4.12.1 及更高版本中正式发布。

Metro-DR 解决方案确保在数据中心不可用期间确保保护和业务连续性,同时使用多个集群同步复制。在公有云中,它们类似于防止可用性区域失败。这个解决方案提供在没有数据丢失的情况下快速恢复应用程序。

如需更多信息,请参阅 planning guideMetro-DR solution for OpenShift Data Foundation 指南。

2.2. 单一节点 OpenShift 集群的逻辑卷管理器存储正式发行

逻辑卷管理器存储为单一节点 OpenShift 集群提供动态块存储,其中资源限制比多样的功能和数据弹性更重要。它的一个应用是电信市场中的 Radio 访问网络(RAN)。如需更多信息,请参阅使用 RHACM 安装 LVM 存储

注意

在以前的版本中,产品名为 OpenShift Data Foundation - Logical Volume Manager。正式发布后,它已被重命名为逻辑卷管理器存储 (LVM 存储或 LVMS)。

从这个版本开始,除了动态存储外,逻辑卷管理器存储还提供以下新功能:

第 3 章 功能增强

这部分论述了 Red Hat OpenShift Data foundation 4.12 中引入的主要改进。

3.1. 单堆栈 IPv6 支持

Red Hat OpenShift Data Foundation 现在支持单一堆栈 IPv6。如需更多信息,请参阅单堆栈 IPv6 支持

3.2. 支持使用 KMIP 的 KMS 供应商

此发行版本引进了使用密钥管理互操作性协议 (KMIP) 的密钥管理系统 (KMS) 供应商的支持,该协议使用客户端证书进行身份验证。Thales CipherTrust Manager 可以与 OpenShift Data Foundation 4.12 一起正常工作。如需更多信息,请参阅 CipherTrust Manager

3.3. 调整日志的详细程度

调试日志消耗的空间量可能会成为严重的问题。调试日志消耗的空间可能会造成一些问题。在这个版本中,可以对其进行调整,从而控制调试日志可以消耗的存储量。如需更多信息,请参阅调整日志的详细程度

3.4. 传输中加密(Encryption in transit)

在这个版本中,IPsec 框架为用于 pod 和服务的虚拟网络提供传输加密。虚拟网络由 Open Virtual Network (OVN)-Kubernetes Container Network Interface (CNI) 插件提供。如需更多信息,请参阅规划指南中的传输加密

3.5. 支持对多云对象网关 PV 池 pod 的资源修改

此功能增强允许您微调基于多云对象网关 (MCG) 持久性卷 (PV) 池的后备存储性能。它提供修改基于 PV 池的后备存储的 CPU 和内存资源和限制,以提高其工作负载的 MCG 性能。

如需更多信息,请参阅创建本地持久性卷支持的后备存储

3.6. Multicloud 对象网关的安全模式部署

在这个版本中,可以以安全模式部署多云对象网关 (MCG),并限制任何外部访问。这提供了对有权访问 MCG 部署的子网进行精细控制。如需更多信息,请参阅为多云对象网关启用安全模式部署

第 4 章 技术预览

本节介绍了 Red Hat OpenShift Data Foundation 4.12 中在技术预览支持限制下引入的技术预览功能。

重要

红帽产品服务级别协议(SLA)不支持技术预览功能,且其功能可能并不完善,因此红帽不建议在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

技术预览功能提供了有限的支持范围,如客户门户网站所述: 技术预览功能支持范围

4.1. OpenShift Workloads 的灾难恢复解决方案

OpenShift Data Foundation 灾难恢复(DR) 功能可在多个 OpenShift Container Platform 集群间启用 DR,并分类如下:

  • 区域灾难恢复 (Regional-DR)

    地区-DR 解决方案为块卷、异步复制和保护业务功能(当地理位置存在灾难)时提供自动保护。在公有云中,这类似于防止区域故障。如需更多信息,请参阅 planning guideRegional-DR solution for OpenShift Data Foundation 指南。

  • Red Hat Advanced Cluster Management 控制台中的多集群监控

    多集群监控是存储健康的单一简化视图,并在多个集群中分布容量。通过这个多集群监控,您可以管理存储容量,并监控 Red Hat Advanced Cluster Management (RHACM )用户界面中的 OpenShift Data Foundation 集群。这个监控功能适用于 DR 和非DR 集群。如需更多信息,请参阅监控多集群存储健康状况

  • CephFS 卷异步可用性区域 DR

    Regional-DR 解决方案现在通过添加 Regional-DR 任务来扩展客户 DR 工作负载功能,如 orchestration、failover 和 relocate on CephFS 控制台,它使用与 Ceph RBD 卷上带有 Regional-DR 的 OpenShift Data Foundation 体验类似的 OpenShift Data Foundation 体验。如需更多信息,请参阅规划指南Regional-DR 解决方案指南

第 5 章 开发人员预览

本节介绍 Red Hat OpenShift Data Foundation 4.12 中引入的开发人员预览功能。

重要

开发人员预览功能可能会受开发人员预览支持限制。开发人员预览版本不应在生产环境中运行。使用开发人员预览功能部署的集群被视为开发集群,不受红帽客户门户网站问题单管理系统的支持。如果您需要开发人员预览功能的帮助,请联络 ocs-devpreview@redhat.com 邮件列表和红帽开发团队成员将根据其可用性和工作计划尽快为您提供协助。

5.1. 副本 1 (非弹性池)

在应用程序级别管理弹性的应用程序现在可以使用具有单一副本的存储类而无需数据弹性和高可用性。

5.2. 网络文件系统新功能

在这个版本中,OpenShift Data Foundation 为任何内部或外部应用程序提供网络文件系统 (NFS) v4.1 和 v4.2 服务。NFS 服务有助于将数据从任何环境迁移到 OpenShift 环境,例如:从 Red Hat Gluster Storage 文件系统迁移到 OpenShift 环境。NFS 功能还包括卷扩展、快照创建和删除以及卷克隆。

如需更多信息,请参阅 Resource requirements for using Network File systemCreating exports using NFS

5.3. 允许 rook-ceph-operator-config 环境变量更改升级时的默认值

在这个版本中,当 OpenShift Data Foundation 从版本 4.5 升级到另一个版本时,允许 rook-ceph-operator-config 环境变量更改默认值。这在早期版本中不可能。

5.4. 轻松配置 Ceph 目标大小比率

在这个版本中,可以对任何池更改目标大小比率。在以前的版本中,Ceph 集群中由 rook 部署的池为 RBD 和 CephFS 数据分配 target_ratio0.49,这可能会导致 RBD 池分配 PG 并为 CephFS 元数据池分配 PG。如需更多信息,请参阅配置池目标大小比率

5.5. pod 的临时存储

临时卷支持允许用户在其 pod 规格中指定临时卷,并将 PVC 的生命周期与 pod 绑定。

5.6. OpenShift Data Foundation 中 RGW 的多站点配置

此功能支持多站点配置,如用于内部或外部 OpenShift Data Foundation 集群的 Zone、ZoneGroup 或 Realm。此设置有助于将数据复制到不同的站点,并在失败时恢复数据。

5.7. 仅在单一节点集群中多云对象网关 (MCG)

在本发行版本中,使用 MCG 在本地存储之上分层的 MCG 为单一节点 OpenShift (SNO) 集群提供了一个轻量级对象存储解决方案。在以前的版本中,在 SNO 上运行的部署只能使用块存储。

5.8. 使用可信证书来确保事务安全且私有

此功能在使用外部模式时,为 OpenShift Data Foundation 和 Red Hat Ceph Storage 之间的对象存储提供 in-transit 加密。它允许在传输中加密所有数据以及在不使用时进行加密。如需更多信息,请参阅知识库文章如何使用可信证书

第 6 章 程序错误修复

这部分论述了 Red Hat OpenShift Data Foundation 4.12 中引入的显著程序错误修复。

6.1. 灾难恢复

  • async 复制将不再可以被设置为 0

    在以前的版本中,您可以为 Sync schedule 输入任何值。这意味着您可以将 async 复制设置为 0,这会导致错误。在这个版本中,引入了一个数字输入,它将不允许小于 1 的值。async 复制现在可以正常工作。

    (BZ#2114501)

  • 现在,删除应用程序可以正确地删除 pod 和 PVC

    在以前的版本中,当从 RHACM 控制台删除应用程序时,DRPC 不会被删除。不删除 DRPC 会导致删除 VRG 和 VR。如果没有删除 VRG/VR,则 PVC finalizer 列表不会被清理,从而导致 PVC 处于 Terminating 状态。

    在这个版本中,从 RHACM 控制台删除应用程序会删除受管集群上所需的依赖 DRPC 和相关资源,释放 PVC 以及所需的垃圾回收。

    (BZ#2108716)

  • 从负载故障转移中删除内部的 VolumeReplicaitonGroup 资源或从不再造成错误的地方重新定位

    由于灾难恢复(DR)协调器中的一个错误,在删除受管集群上的内部 VolumeReplicaitonGroup 资源时,工作负载会从其中失败或重定位,则会对持久性卷声明(PVC)进行保护。生成的清理操作没有完成,并将应用程序的 DRPlacementControl 上的 PeerReady 条件报告为 False。这意味着,如果应用程序被过度或重新定位失败,无法再次重新定位或失败,因为 DRPlacementControl 资源会报告其 PeerReady 条件为 False

    在这个版本中,在删除内部 VolumeReplicationGroup 资源时,不会尝试再次保护 PVC,从而避免出现停止清理的问题。这会导致 DRPlacementControl 在完成清理后报告 PeerReadyTrue

    (BZ#2116605)

6.2. 多云对象网关

  • 在等待 StorageClass 创建时 StorageCluster 不再会进入到 Error 状态

    在创建 Red Hat OpenShift Data Foundation StorageCluster 时,它会在 StorageClass 被创建前等待创建底层池。在这段时间中,集群会返回协调请求的错误,直到池就绪为止。由于这个错误,StorageClusterPhase 被设置为 Error。在这个版本中,在创建池的过程中会发现这个错误,StorageClusterPhaseProgressing

    (BZ#2004027)

6.3. CephFS

  • 从 RHCS 5.1 更新至更新的版本时,存储桶元数据不再有问题

    Red Hat Ceph Storage (RHCS) 版本 5.1 附带的 RADOS 网关 (RGW) 会意外地包含与 not-yet-GA 支持相关的逻辑,支持多站点复制设置中的动态 bucket-index 重新划分。这个逻辑从 RHCS 5.2 中删除。此历史记录的副作用是已升级到 RHCS 5.1 的站点无法升级到 RHCS 5.2,因为版本 5.2 的存储桶元数据处理与 RHCS 5.1 不兼容。现在,在升级到 RHCS 5.3 时可以解决这个情况。因此,RHCS 5.3 可以在所有之前版本中创建的存储桶上运行,包括 5.1。

    (BZ#2115645)

6.4. OpenShift Data Foundation operator(操作器)

  • 安装 ODF operator 时,不再有 Pod Security Violation Alert

    OpenShift Data Foundation 版本 4.11 引入了新的 POD Security Admission 标准,它会在运行特权 Pod 时发出警告。ODF operator 部署使用几个需要特权访问权限的 pod。因此,在部署了 ODF operator 后,Pod Security Violation 警报会启动触发。

    在这个版本中,OLM 会根据相关的 Pod Security Admission 标准自动标记命名空间,该命名空间使用 openshift-* 前缀。

    (BZ#2110628)

第 7 章 已知问题

本节介绍了 Red Hat OpenShift Data Foundation 4.12 中已知的问题。

7.1. 灾难恢复

  • 故障转移操作报告 pod 上的 RADOS 块设备镜像挂载在仍然在使用中的 RPC 错误时失败

    在灾难恢复(DR)受保护的工作负载时,可能会导致在故障转移集群中使用卷处于卡住的 pod,报告 RADOS 块设备(RBD)镜像仍在使用。这可防止 pod 在很长时间内启动(最多几个小时)。

    (BZ#2007376)

  • 故障转移操作报告 pod 上 RADOS 块设备镜像挂载在具有 RPC 错误 fsck 的 pod 上失败

    如果出现灾难恢复(DR)受保护的工作负载,则可能会导致 pod 启动掉状态为文件系统一致性检查(fsck)错误的卷挂载错误。这可防止工作负载切换到故障转移集群。

    (BZ#2021460)

  • 为受管集群创建应用程序命名空间

    应用程序命名空间需要存在于 RHACM 受管集群中,用于灾难恢复 (DR) 相关的预部署操作,因此当应用程序部署在 RHACM hub 集群中时预先创建。但是,如果在 hub 集群中删除某个应用程序,并且在受管集群中删除对应的命名空间,则会在受管集群上重新应用。

    临时解决方案: openshift-dr 在 RHACM hub 的受管集群命名空间中维护一个命名空间 manifestwork 资源。需要在应用程序删除后删除这些资源。例如,作为集群管理员,在 hub 集群上执行以下命令: oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw

    (BZ#2059669)

  • 对于某些镜像,RBD 镜像调度已停止

    Ceph 管理器守护进程会因为不同的原因而获得 blocklist,这会导致在镜像的主集群中触发调度的 RBD 镜像快照。当使用 rbd mirror snapshot schedule status -p ocs-storagecluster-cephblockpool 检查时,镜像启用了 DR 保护的所有 RBD 镜像都不会被列出,因此不会主动镜像到对等站点。

    临时解决方案:在镜像为主的受管集群中重启 Ceph 管理器部署,可以针对当前运行的实例克服 blocklist,这可以通过缩减并稍后扩展 ceph 管理器部署来实现:

    $ oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=0
    $ oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=1

    结果:在使用 rbd mirror snapshot schedule status -p ocs-storagecluster-cephblockpool 检查时,受管集群上启用 DR 的镜像开始报告镜像调度

    (BZ#2067095)

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

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

    (BZ#2100920)

  • Ceph 无法识别 Globalnet 分配的全局 IP

    Ceph 不识别 Globalnet 分配的全局 IP,因此无法使用 Globalnet 在带有重叠服务 CIDR 的集群间配置灾难恢复解决方案。由于当服务 CIDR 重叠时,这个灾难恢复解决方案无法正常工作。

    (BZ#2102397)

  • 这两个 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 资源管理,不会造成任何操作和数据不一致。

    (BZ#2111163)

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

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

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

    (BZ#2114573)

  • 应用程序在重新定位过程中处于 Relocating 状态

    Multicloud Object Gateway 允许将相同名称或命名空间的多个持久性卷 (PV) 对象添加到同一路径的 S3 存储中。因此,Ramen 不会恢复 PV,因为它检测到指向同一 claimRef 的多个版本。

    临时解决方案:使用 S3 CLI 或等同于从 S3 存储清理重复的 PV 对象。仅保持接近故障转移或重新定位时间的时间戳的那一个。

    结果:恢复操作将继续完成,故障切换或重新定位操作会继续下一步。

    (BZ#2120201)

  • 当一个区出现问题时,应用程序会处于 FailingOver 状态

    在故障转移或重新定位时,如果没有 s3 存储,则故障转移或重新定位进程挂起。如果 DR 日志指出 S3 存储无法访问,那么故障排除并获取 s3 存储操作将使得 DR 能够继续故障转移或重新定位操作。

    (BZ#2121680)

  • 当工作负载通过或重新定位到对等集群时,PeerReady 状态被设置为 true,直到从中清理或重新定位的集群为止

    启动灾难恢复 (DR) 操作后,当工作负载故障转移或重新定位到对等集群时,PeerReady 条件会在持续时间内最初设置为 true。当它被设置为 false 后,直到从中清理或重新定位的集群才会从其中清理或重新定位到将来的操作。查看 DRPlacementControl 状态条件的用户,用于将来的操作可能会将这个中间 PeerReady 状态识别为对等状态,以进行操作并执行。这将导致操作等待或失败,并可能需要用户干预才能从中恢复。

    临时解决方案:在执行任何操作前检查 AvailablePeerReady 状态。对于工作负载的健康的 DR 状态,两者都为 true。当两个状态都为 true 时执行的操作将导致请求的操作进度

    (BZ#2138855)

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

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

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

    (BZ#2159791)

  • 阻塞列表可能会导致 Pod 处于错误状态

    防止网络问题或大量过载或具有大量尾部延迟激增的集群阻止列表。因此,Pods 会停留在 CreateContainerError,并带有信息 Error: relabel failed /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount: lsetxattr /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount/#ib_16384_0.dblwr: read-only file system

    临时解决方案:重新引导将这些 pod 被调度到的节点,并参照以下步骤:

    1. cordon 然后排空有问题的节点
    2. 重新引导有问题的节点
    3. Uncordon 有问题的节点

    (BZ#2094320)

7.2. CephFS

  • CephFS 上扩展集群的性能不佳

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

    (BZ#1982116)

7.3. OpenShift Data Foundation 控制台

  • OpenShift Data Foundation 仪表板在升级后崩溃

    当升级 OpenShift Container Platform 和 OpenShift Data Foundation 时,在点仪表板链接时,Storage 部分中的 Data Foundation 仪表板会崩溃并带有 "404: Page not found" 错误。这是因为没有出现刷新控制台的弹出窗口。

    临时解决方案:执行控制台的硬刷新。这会返回仪表板,它将不会再崩溃。

    (BZ#2157876)

第 8 章 异步勘误更新

8.1. RHSA-2023:4287 OpenShift Data Foundation 4.12.5 程序错误修复和安全更新

OpenShift Data Foundation 版本 4.12.5 现已正式发布。此更新包括的程序错误修正信息包括在 RHSA-2023:4287 公告中。

8.2. RHSA-2023:3609 OpenShift Data Foundation 4.12.4 程序错误修复和安全更新

OpenShift Data Foundation 版本 4.12.4 现已正式发布。此更新包括的程序错误修正信息包括在 RHSA-2023:3609 公告中。

8.3. RHSA-2023:3265 OpenShift Data Foundation 4.12.3 程序错误修复和安全更新

OpenShift Data Foundation 版本 4.12.3 现已正式发布。此更新包括的程序错误修正信息包括在 RHBA-2023:3265 公告中。

8.4. RHBA-2023:1816 OpenShift Data Foundation 4.12.2 程序错误修复和安全更新

OpenShift Data Foundation 版本 4.12.2 现已正式发布。此更新包括的程序错误修正信息包括在 RHBA-2023:1816 公告中。

8.5. RHBA-2023:1170 OpenShift Data Foundation 4.12.1 程序错误修复和安全更新

OpenShift Data Foundation release 4.12.1 现已正式发布。此更新包括的程序错误修正信息包括在 RHBA-2023:1170 公告中。

8.5.1. 新功能

Metropolitan 灾难恢复(Metro-DR)解决方案正式发布

Red Hat Advanced Cluster Management for Kubernetes 2.7 的 Red Hat OpenShift Data Foundation Metro-DR 功能现已正式发布。

注意

Block 和 Files 的 Regional-DR 解决方案作为技术预览提供,并受技术预览支持限制。

如需更多信息,请参阅 planning guideMetro-DR solution for OpenShift Data Foundation 指南。

8.5.2. 功能增强

修复了 COS 发现的读取性能问题

在这个改进中,多云对象网关数据库的读取操作性能有所改进。为实现此目的,需要预先编译对数据库运行的一些查询使用的某些正则表达式。这会节省实时运行时的时间。(BZ#2149861)

为断开连接的环境支持和 RelatedImages 字段添加了过去 CSV 缺少的注解

multicluster-orchestrator Operator 在支持带有此功能增强的断开连接的模式的 Operator 下列出。要显示此 Operator,断开连接的模式支持注解会作为用户界面 (UI) 使用这个注解添加到 CSV 中。(BZ#2166223)

8.5.3. 已知问题

无法从 hub 控制台启动应用程序的故障切换

在使用主动/被动 Hub Metro-DR 设置时,您可能会遇到罕见的场景,Ramen 协调器会在超过其允许速率限制参数后停止运行。因为协调特定于每个工作负载,因此只有该工作负载会受到影响。在这种情况下,与那个工作负载相关的所有灾难恢复编配活动停止直到 Ramen pod 重启为止。

临时解决方案:重启 Hub 集群上的 Ramen pod。

$ oc delete pods <ramen-pod-name> -n openshift-operators

(BZ#2175201)

重复活跃 hub 区失败后无法从控制台故障转移应用程序

在多个 hub 恢复过程中,当出现双故障(如 hub 和受管集群都停机时),如果最后操作被重新定位,则可能无法从 RHACM 控制台启动故障切换。

临时解决方案:使用 CLI 将 DRPC.spec.action 字段设置为 Failover。

$ oc edit drpc -n app-1  app-1-placement-1-drpc
spec
  action: Failover

结果:对工作负载进行故障将启动到故障转移集群。

(BZ#2176028)