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 및 MCG(Multicloud Object Gateway)만 설치되고 'odf-operator'가 클러스터에서 누락됩니다.
해결방법: GUI(그래픽 사용자 인터페이스) 또는 백엔드에서 odf-operator를 설치합니다. 백엔드를 통해 서브스크립션 이름을 생성하는 경우 서브스크립션 이름이 odf-operator인지 확인합니다.
Multicloud Object Gateway 비보안 스토리지 계정에서 TLS 1.2를 지원하지 않음
MCG(Multicloud Object Gateway)는 TLS(Transport Layer Security) 1.2로 구성된 Microsoft Azure 스토리지 계정을 지원하지 않습니다. 따라서 1.2 정책만 있는 스토리지 계정에 기본 백업 저장소 또는 새 백업 저장소를 만들 수 없습니다.
스토리지 클러스터를 다시 설치하는 동안 cephobjectstore 용 Cep 개체 사용자를 생성하지 못하는 경우 arbiter 스토리지 클러스터 설치 후 치명적인 경고 알림이 전송됩니다.
CephCluster 및 하나 이상의 CephObjectStores가 포함된 스토리지 클러스터에서는 모든 CephObjectStore 리소스가 완전히 삭제되기 전에 CephCluster 리소스가 삭제되면 Rook Operator는 CephObjectStores에 대한 연결 세부 정보를 메모리에 계속 유지할 수 있습니다. 동일한 CephCluster 및 CephObjectStores가 다시 생성되는 경우 CephObjectStores가 Failed 상태가 될 수 있습니다.
이 문제를 방지하려면 CephCluster를 제거하기 전에 CephObjectStores를 완전히 삭제할 수 있습니다. CephObjectStores가 삭제될 때까지 기다리지 않으려면 제거 후 Operator Pod를 삭제하여 Rook Operator를 다시 시작하여 문제를 방지합니다. 이 문제가 발생하면 Rook Operator를 다시 시작하여 이전 CephObjectStore 연결 세부 정보의 Operator 메모리를 지워 문제를 해결합니다.
(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 생성 자동화
현재 ocs-metrics-exporter에서 prometheus-user라는 Ceph 오브젝트 저장소 사용자가 예상하므로 OBC(오브젝트 버킷 클레임) 지표 수집이 실패합니다.
해결방법: 수동으로 prometheus-user를 생성하고 스토리지 클러스터 생성 후 적절한 권한을 제공합니다. 자세한 내용은 기술 자료 문서 https://access.redhat.com/articles/6541861의 사전 요구 사항 섹션을 참조하십시오.
StorageCluster 및 StorageSystem ocs-storagecluster는 StorageSystem을 설치할 때 몇 분 동안 오류 상태에 있습니다.
StorageCluster 생성 중에 성공/준비 상태로 이동하기 전에 오류 상태로 표시되는 작은 시간 표시 창이 있습니다. 이는 간헐적이지만 예상되는 동작이며 일반적으로 자체적으로 해결됩니다.
해결방법: 대기 상태 메시지 또는 로그에서 자세한 정보를 확인합니다.
키가 대문자로 지정된 경우 테넌트 구성이 백엔드 경로를 재정의하지 않음
테넌트 네임스페이스에 설정된 KMS(Key Management Service) 공급자 옵션은 OpenShift Container Storage 사용자 인터페이스에서 지원하는 키/값 설정보다 더 고급 설정입니다. 결과적으로 테넌트 네임스페이스에 설정된 KMS 공급자의 구성 옵션은 대문자 대신 카멜 표기법 (camel case)으로 포맷해야 합니다. openshift-storage 네임스페이스의 KMS 공급자 구성에 대한 액세스 권한이 있는 사용자와 openshift-storage 네임스페이스의 옵션으로 Tenants 네임스페이스의 구성이 대문자인 반면 Tenants 네임스페이스의 옵션은 다음과 같이 구성되어 있어 혼동을 줄 수 있습니다.
해결방법: KMS 공급자 옵션에 대한 카멜 표기법 포맷을 사용합니다.
장애 조치(failover)를 통해 오류가 발생한 보호된 애플리케이션을 삭제해도 보조 또는 장애 조치 사이트의 RADOS 블록 장치 이미지가 삭제되지 않습니다.
재해 복구(DR) 보호 워크로드를 삭제하면 보조 DR 클러스터에서 RADOS 블록 장치(RBD) 이미지가 누출될 수 있습니다. 삭제된 이미지는 보조 클러스터에서 공간을 차지합니다. 이 문제를 해결하려면 toolbox Pod를 사용하여 DR 보호에 더 이상 사용되지 않는 보조 클러스터에서 이미지를 감지하고 정리합니다. 이 해결방법을 통해 보조 클러스터에서 공간 복제를 수행할 수 있습니다.
장애 조치 작업에서는 RPC 오류가 still in use인 Pod에서 RADOS 블록 장치 이미지 마운트에 실패했습니다.
재해 복구(DR) 보호 워크로드를 통해 실패하면 Pod에서 RADOS 블록 장치(RBD) 이미지가 여전히 사용 중인 것으로 보고되는 장애 조치 클러스터의 볼륨을 사용할 수 있습니다. 이렇게 하면 Pod가 오랜 기간(최대 몇 시간) 동안 시작되지 않습니다.
재배치 작업 결과 PVC의 종료 상태 및 워크로드가 기본 클러스터로 이동되지 않음
재해 복구(DR) 보호 워크로드를 재배치하는 동안 워크로드는 현재 기본 클러스터 및 종료 상태에 남아 있는 워크로드의 PVC에서 중지되지 않습니다. 이렇게 하면 Pod 및 PVC가 기본 클러스터로 재배치되지 않습니다. 문제를 복구하려면 장애 조치 조치를 수행하여 워크로드를 기본 클러스터로 이동합니다. 워크로드는 기본 클러스터에서 복구되지만 장애 조치(failover)이므로 데이터 손실이 포함될 수 있습니다.
장애 조치 작업에서는 RPC 오류 fsck를 사용하여 Pod에서 RADOS 블록 장치 이미지 마운트 실패를 보고합니다.
재해 복구(DR) 보호 워크로드를 통해 실패하면 볼륨에 파일 시스템 일관성 검사(fsck) 오류가 있는 볼륨 마운트 오류로 인해 Pod가 시작되지 않을 수 있습니다. 이로 인해 워크로드가 장애 조치(failover) 클러스터로 장애 조치되지 않습니다.
Overprovision Level Policy Control은 사용자 정의 스토리지 클래스를 지원하지 않습니다.
OpenShift Data Foundation은 overprovision-control에서 허용된 스토리지 클래스를 Ceph 하위 유형으로만 제한합니다. 결과적으로 overprovision-control 에 사용자 정의 스토리지 클래스를 사용하는 경우 StorageCluster CRD가 유효하지 않은 것으로 정의되고 스토리지 클래스에 overprovision-control 이 있을 수 없습니다.
