第 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
当集群处于扩展模式时,Ceph
df
会报告一个无效的 AVAIL 值当 Red Hat Ceph Storage 集群的 crush 规则具有多个"take"步骤时,
ceph df
报告显示该映射的最大可用大小。这个问题将在即将推出的版本中解决。
这两个 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 资源管理,不会造成任何操作和数据不一致。
MongoDB pod 处于
CrashLoopBackoff
,因为的权限错误读取cephrbd
卷中的数据跨不同受管集群的 OpenShift 项目具有不同的安全性上下文约束 (SCC),这在指定的 UID 范围和/或
FSGroups
中有所不同。这会导致某些工作负载 pod 和容器无法在这些项目中启动后故障转移或重新定位操作,因为日志中的文件系统访问错误。临时解决方案:确保在所有带有同一项目级别的 SCC 标签的受管集群中创建工作负载项目,以便在通过或重新定位失败时使用相同的文件系统上下文。Pod 不再对文件系统相关的访问错误失败失败。
灾难恢复工作负载在删除时会卡住
当从集群中删除工作负载时,对应的 pod 可能无法与
FailedKillPod
等事件终止。这可能会导致垃圾收集依赖的 DR 资源(如PVC
、VolumeReplication
和VolumeReplicationGroup
)的延迟或失败。它还可防止以后将相同的工作负载部署到集群中,因为过时的资源还没有垃圾回收。临时解决方案:重启正在运行 pod 的 worker 节点,并处于终止状态。这会导致 pod 终止以及随后相关的 DR API 资源被收集垃圾回收。
基于区域 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 保护的资源,则错误可以被忽略。
禁用
PeerReady
标志可防止将操作改为 FailoverDR 控制器根据需要执行完全协调。当集群无法访问时,DR 控制器会执行完整性检查。如果工作负载已重新定位,则此 sanity 检查会导致与工作负载关联的
PeerReady
标志被禁用,因为集群离线,sanity 检查不会完成。因此,禁用PeerReady
标志可防止您将操作改为 Failover。临时解决方案:即使禁用了
PeerReady
标志,使用命令行界面将 DR 操作改为 Failover。
当连接在扩展集群的两个数据中心之间丢失连接时,Ceph 变得无法访问,并且 IO 暂停
当两个数据中心相互丢失但仍然连接到 Arbiter 节点时,在选择逻辑中存在一个缺陷,这会导致监视器之间有无限选举。因此,监控器无法选举领导,Ceph 集群将不可用。另外,IO 在连接丢失过程中暂停。
临时解决方案:在监控没有仲裁(您可以通过运行
ceph -s
命令)中关闭 monitor,并重置剩余的 monitor 的连接分数。因此,监控器可以形成仲裁,Ceph 会再次可用,IOs 恢复。
在从替换集群中使用过时的 Ceph 池 ID 时,RBD 应用无法分配
对于在创建新对等集群之前创建的应用,无法挂载 RBD PVC,因为当替换对等集群时,无法更新 CSI configmap 中的 CephBlockPoolID 的映射。
临时解决方案:在未替换的对等集群中,将
rook-ceph-csi-mapping-config
configmap 更新为 cephBlockPoolID 的映射。这将启用为应用挂载 RBD PVC。
有关
lastGroupSyncTime
的信息会在 hub 恢复后丢失,这些工作负载在不可用受管集群上是主的以前失败的应用程序不会报告
lastGroupSyncTime
,从而导致警报VolumeSynchronizationDelay
触发。这是因为当 ACM hub 和作为 DRPolicy 一部分的受管集群不可用时,从备份中重建新的 ACM hub 集群。临时解决方案:如果工作负载失败的受管集群不可用,您仍可以切换到一个存活的受管集群。
MCO operator 协调
veleroNamespaceSecretKeyRef
和CACertificates
字段当 OpenShift Data Foundation Operator 升级时,Ramen 配置中的
s3StoreProfiles
下的CACertificates
和veleroNamespaceSecretKeyRef
字段将会丢失。临时解决方案:如果 Ramen 配置具有
CACertificates
和veleroNamespaceSecretKeyRef
字段的自定义值,则在执行升级后如何设置这些自定义值。
升级后 token-exchange-agent pod 的不稳定
受管集群中的
token-exchange-agent
pod 不稳定,因为旧的部署资源不会被正确清理。这可能导致应用程序故障切换操作失败。临时解决方案: 在升级到 ODF 4.16.0 后,请参阅知识库文章 "token-exchange-agent" pod 不稳定。
结果:如果遵循这个临时解决方案,"token-exchange-agent" pod 是 stabilized,故障转移操作可以正常工作。
VirtualMachines.kubevirt.io
资源因为重新定位中的 mac 分配失败而无法恢复当虚拟机重新定位到首选集群时,由于 mac 地址不可用,它可能无法完成重新定位。如果虚拟机在故障转移集群时没有完全清理在首选集群中,会出现这种情况。
在重新定位工作负载前,请确保工作负载从首选集群完全删除。
在 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-<>-<>
当还没有创建
ReplicationDestination
资源时,故障转移过程会失败如果用户在
LastGroupSyncTime
更新前启动故障转移,故障转移过程可能会失败。此失败由一条错误消息指示ReplicationDestination
不存在。临时解决方案:
编辑 hub 集群上 VRG 的
ManifestWork
。从清单中删除以下部分:
/spec/workload/manifests/0/spec/volsync
保存更改。
正确应用此临时解决方案可确保 VRG 跳过使用
ReplicationDestination
资源恢复 PVC。如果 PVC 已存在,应用程序会原样使用。如果 PVC 不存在,则会创建新的 PVC。