第 7 章 已知问题
本节介绍 Red Hat OpenShift Data Foundation 4.9 中已知的问题。
当 OpenShift Container Storage 从版本 4.8 升级到 4.9 时，缺少 odf-operator
目前，在升级 ocs-operator 时，如果您在不安装 odf-operator 的情况下更改 OpenShift Container Storage 订阅的频道，集群只会安装 OpenShift Data Foundation 和 Multicloud Object Gateway(MCG)，且集群中的 'odf-operator' 将丢失。
临时解决方案：从图形用户界面(GUI)或后端安装 odf-operator。如果通过后端创建订阅，请确保订阅名称为 odf-operator。
Multicloud Object Gateway insecure 存储帐户不支持 TLS 1.2
Multicloud Object Gateway(MCG)不支持使用传输层安全(TLS)1.2 配置的 Microsoft Azure 存储帐户。因此，您无法在仅使用 1.2 策略的存储帐户中创建默认后备存储或任何新的后备存储。
当在存储集群重新安装的过程中无法创建 cephobjectstore 用户时，在安装了仲裁存储集群后会发出关键警报通知。
在包含 CephCluster 和一个或多个 CephObjectStores 的存储集群中，如果在所有 CephObjectStore 资源之前删除 CephCluster 资源，则 Rook Operator 仍可在内存中保存 CephObjectStores 的连接详情。如果重新创建相同的 CephCluster 和 CephObjectStores，Ceph ObjectStores 可能会进入 Failed 状态。
要避免这个问题，您可以在删除 CephCluster 前完全删除 CephObjectStores。如果您不想等待 CephObjectStores 被删除，请重启 Rook Operator（通过删除 Operator Pod）以避免在卸载后出现问题。如果您主动遇到这个问题，重启 Rook Operator 以通过清除旧 CephObjectStore 连接详情来解决此问题。
(BZ#1974344)
在 CephFS 上扩展集群性能不佳
具有许多小元数据操作的工作负载可能会因为在多站点 OpenShift Data Foundation 集群上放置元数据服务器(MDS)造成性能不佳。
当 OpenShift Container Storage 从版本 4.5 升级到另一版本时，则不会更新 rook-ceph-operator-config ConfigMap
OCS-operator 使用 rook-ceph-operator-config ConfigMap 来配置 rook-ceph-operator 行为，但它仅创建一次，但不会协调它。这将引发问题，它不会在产品发展时更新默认值。
临时解决方案：管理员可以手动更改 rook-ceph-operator-config 值。
自动为对象存储桶声明指标收集器创建 cephobjectstoreuser
目前，对象存储桶声明(OBC)指标集合会失败，因为 ocs-metrics-exporter 需要名为 prometheus-user 的 Ceph 对象存储用户。
临时解决方案：手动创建 prometheus-user，并在存储集群创建后提供适当的权限。如需更多信息，请参阅知识库文章 https://access.redhat.com/articles/6541861 的先决条件部分。
安装 StorageSystem 时，Storagecluster 和 StorageSystem ocs-storagecluster 会处于错误状态。
在 StorageCluster 创建过程中，在进入成功/就绪状态前，会有一个小的时间窗口显示处于错误状态。这是一个间歇性的、但在预期中的行为，通常会自行解决。
临时解决方案： 等待和监视状态消息或日志以了解更多信息。
如果以大写形式指定了密钥，租户配置不会覆盖 backendpath
Tenants 命名空间中设置的密钥管理服务(KMS)供应商选项比 OpenShift Container Storage 用户界面支持的键/值设置更为高级。因此，Tenants 命名空间中设置的 KMS 供应商的配置选项的格式需要是驼峰式大小写（camel case），而不是大写。可以访问 openshift-storage 命名空间中的 KMS 供应商配置的用户可能会令人困惑，并且作为 openshift-storage 命名空间中的选项，如 openshift-storage 命名空间中的选项为大写，而 Tenants 命名空间中的选项则为 camel case。
临时解决方案：将 camel case Format 用于 KMS 供应商选项。
删除已接管且之后失败的受保护的应用不会删除次要或故障转移站点上的 RADOS 块设备镜像
删除灾难恢复(DR)受保护的工作负载可能会泄漏次要 DR 集群中的 RADOS 块设备(RBD)镜像。然后，删除的镜像会在辅助集群上的占用空间。要解决这个问题，使用 toolbox pod 检测并清理次要集群中不再用于 DR 保护的镜像。这个临时解决方案可确保辅助集群中的空间回收。
故障转移操作会报告 RADOS 块设备镜像挂载在 pod 上失败，但仍使用 RPC 错误
在灾难恢复(DR)受保护的工作负载时，可能会导致在故障转移集群中使用卷处于卡住的 pod，报告 RADOS 块设备(RBD)镜像仍在使用。这可防止 pod 在很长时间内启动（最多几个小时）。
重新定位操作会导致 PVC 的终止状态，工作负载不会移到首选集群
在重新定位灾难恢复(DR)受保护的工作负载时，会导致工作负载在当前主集群中停止，而 PVC 则保留在终止状态。这可防止 pod 和 PVC 重新定位到首选集群。要恢复这个问题，请执行故障转移操作，将工作负载移到首选集群。工作负载将在首选集群中恢复，但可能会在操作过程中纳入数据丢失。
故障转移操作报告 RADOS 块设备镜像在 pod 上失败，并显示 RPC 错误 fsck
如果出现灾难恢复(DR)受保护的工作负载，则可能会导致 pod 启动掉状态为文件系统一致性检查(fsck)错误的卷挂载错误。这可防止工作负载切换到故障转移集群。
Overprovision Level Policy Control 不支持自定义存储类
OpenShift Data Foundation 将 overprovision-control 中的允许存储类限制为 Ceph 子类型。因此，如果在 overprovision-control 中使用用户定义的存储类，则 StorageCluster CRD 会被定义为无效，存储类无法具有 overprovision-control。
