第 7 章 已知问题


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

7.1. 灾难恢复

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

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

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

    $ oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw

    (BZ#2059669)

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

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

    (BZ#2100920)

  • 这两个 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#2128860)

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

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

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

    (BZ#2081855)

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

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

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

    (BZ#2159791)

  • 基于区域 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 保护的资源,则错误可以被忽略。

    (BZ-2264445)

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

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

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

    (BZ-2264765)

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

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

    临时解决方案:在监控没有仲裁(您可以通过运行 ceph -s 命令)中关闭 monitor,并重置剩余的 monitor 的连接分数。

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

    (合作伙伴 BZ#2265992)

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

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

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

    (BZ#2267731)

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

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

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

    (BZ#2275320)

  • MCO operator 协调 veleroNamespaceSecretKeyRefCACertificates 字段

    当 OpenShift Data Foundation Operator 升级时,Ramen 配置中的 s3StoreProfiles 下的 CACertificatesveleroNamespaceSecretKeyRef 字段将会丢失。

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

    (BZ#2277941)

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

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

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

    (BZ#2295404)

  • 在 hub 恢复后,订阅应用程序 pod 不会在故障切换后出现

    在 hub 恢复后,订阅应用程序 pod 在从主受管集群切换到二级受管集群后不会出现。RBAC 错误发生在受管集群上的 AppSub 订阅资源中。这是因为备份和恢复场景中出现时间问题。当每个受管集群上重启 application-manager pod 时,hub 订阅和频道资源不会在新 hub 中重新创建。因此,子 AppSub 订阅资源会出错。

    临时解决方案:

    使用以下命令获取 appsub 的名称:

    % oc get appsub -n <namespace of sub app>

    使用以下命令,将带有任何值的新标签添加到 hub 上的 AppSub 中:

    % oc edit appsub -n <appsub-namespace> <appsub>-subscription-1

    如果子 appsub 错误仍存在未知证书问题,请重启工作负载失败的受管集群中的 application-manager pod。

    % oc delete pods -n open-cluster-management-agent-addon application-manager-<>-<>

    (BZ#2295782)

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

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

    临时解决方案:

    编辑 hub 集群上 VRG 的 ManifestWork

    从清单中删除以下部分:

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

    保存更改。

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

    (BZ#2283038)

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.