차단 목록에 더 이상 오류 상태가 되는 Pod가 발생하지 않음

이전 버전에서는 네트워크 문제 또는 과도한 과부하 또는 불균형이 높은 클러스터로 인해 차단 대기 시간이 급증했습니다. 이로 인해 Pod는 Error : relabel failed /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7-4ae7-4ae766: lsetxattr /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80ae7610bb613/mount/#ib_16384_0.dblwr: 읽기 전용 파일 시스템.

이번 수정으로 blocklisting으로 인해 더 이상 오류 상태가 되는 Pod가 발생하지 않습니다.

(BZ#2094320)

Ceph에서 Globalnet에서 할당한 글로벌 IP 인식

이전에는 Ceph가 Globalnet에서 할당한 글로벌 IP를 인식하지 못했기 때문에 Globalnet을 사용하여 서비스 CIDR이 겹치는 클러스터 간에 재해 복구 솔루션을 구성할 수 없었습니다. 이 문제는 해결되었으며 서비스 CIDR이 겹치는 경우 재해 복구 솔루션이 작동합니다.

(BZ#2104971)

PeerReady 상태는 워크로드가 장애 조치되거나 실패한 위치에서 클러스터가 정리될 때까지 워크로드가 장애 조치되거나 피어 클러스터로 재배치될 때 더 이상 true 로 설정되지 않습니다.

이전 버전에서는 재해 복구(DR) 작업이 시작된 후 워크로드가 장애 조치되거나 피어 클러스터로 재배치된 기간 동안 PeerReady 조건이 true 로 설정되었습니다. 이 경우 오류가 발생하거나 재배치된 클러스터가 향후 작업을 위해 정리될 때까지 false 로 설정되었습니다. 향후 작업에 대해 DRPlacementControl 상태 조건을 보는 사용자는 이 중간 PeerReady 상태를 피어가 작업을 준비하고 수행할 준비가 되었음을 인식할 수 있습니다. 이로 인해 작업이 보류 중이거나 실패할 수 있으며 복구하기 위해 사용자 개입이 필요할 수 있습니다.

이번 수정을 통해 클러스터가 정리될 때까지 실패한 워크로드 또는 재배치된 워크로드에서 PeerReady 상태가 더 이상 true 로 설정되지 않으므로 사용자에게 더 이상 혼동이 발생하지 않습니다.

(BZ#2138855)

재해 후 ACM 허브를 복구할 때 애플리케이션이 더 이상 정리 상태로 유지되지 않음

이전에는 ACM 허브가 재해 발생 중에 손실되고 백업을 사용하여 복구되면 VRG ManifestWork 및 DRPC 상태가 복원되지 않았습니다. 이로 인해 애플리케이션이 정리 상태가 되었습니다.

이번 수정으로 Ramen은 VRG ManifestWork가 ACM 백업의 일부임을 확인하고 허브 복구 후 비어 있는 경우 DRPC 상태를 다시 빌드하고 애플리케이션이 장애 조치 클러스터로 성공적으로 마이그레이션됩니다.

(BZ#2162469)

STS 기반 애플리케이션을 이제 예상대로 재배치할 수 있습니다.

이전에는 기본 버그로 인해 STS 기반 애플리케이션을 재배치하지 못했습니다. 이 버그가 수정되었으며 STS 기반 애플리케이션을 재배치하는 것이 이제 예상대로 작동합니다.

(BZ#2224325)

Ramen는 허브 복원 후 예상대로 조정

이전에는 활성/수동 Hub Metro-DR 설정으로 작업하는 동안 허용된 속도 제한 매개변수를 초과한 후 Ramen 조정기에서 실행을 중지하는 드문 경우가 있을 수 있었습니다. 조정은 각 워크로드에 고유하므로 해당 워크로드에만 영향을 미쳤습니다. 이러한 경우 해당 워크로드와 관련된 모든 재해 복구 오케스트레이션 활동이 Ramen pod가 다시 시작될 때까지 중지되었습니다.

이 문제가 해결되었으며 Ramen은 허브 복원 후 예상대로 조정됩니다.

(BZ#2175201)

허브 복구 중에 관리되는 리소스가 더 이상 삭제되지 않음

이전 버전에서는 허브 복구 중에 OpenShift Data Foundation에서 서브스크립션 기반 워크로드와 관련된 특정 관리 리소스가 의도하지 않게 삭제되었을 수 있는 Red Hat Advanced Cluster Management 버전 2.7.4 이상에서 알려진 문제가 발생했습니다.

이 문제는 해결되었으며 허브 복구 중에 관리되는 리소스가 삭제되지 않습니다.

(BZ#2211643)

이제 NooBaa 버킷에서 가상 호스트 스타일을 사용할 수 있습니다.

이전에는 NooBaa 끝점 및 코어에서 DNS 구성 포트를 인식하지 못했기 때문에 Virtual-host 스타일이 NooBaa 버킷에서 작동하지 않았습니다.

이번 업데이트를 통해 NooBa Operator는 DNS 포트를 코어 및 엔드포인트에 전달하여 가상 호스트 스타일을 사용할 수 있습니다.

(BZ#2183092)

더 이상 로그에 Dummy 인증 정보가 출력되지 않음

이전에는 더미 인증 정보가 로그에 출력되어 혼동이 발생할 수 있었습니다. 이 버그는 수정되었으며 인증 정보가 더 이상 인쇄되지 않습니다.

(BZ#2189866)

이제 인증 정보가 제한된 시간에 제공되지 않는 경우 이제 NooBaa가 pv-pool 유형의 백업 저장소를 사용합니다.

예를 들어 NooBaa를 설치하기 전에 클라우드 인증 정보 요청이 생성된 후 클라우드 인증 정보 운영자가 시크릿을 제공할 수 없거나 실패하는 경우 클라우드 인증 정보 Operator 모드를 수동 모드로 설정하고 추가 필요한 작업이 수행되지 않았습니다. 제공된 시크릿에는 기본 백업 저장소에 대한 대상 버킷을 생성하는 데 필요한 인증 정보가 포함됩니다. 즉, 기본 백업 저장소가 생성되지 않았으며 Noobaa가 구성 단계에서 중단되었습니다.

이번 수정을 통해 클라우드 인증 정보 요청이 전송되고 정의된 제한된 시간에 시크릿을 가져올 수 없는 경우 NooBaa는 pv-pool 유형의 백업 저장소를 사용하는 것으로 대체되었습니다. 즉, 시스템은 Ready 상태에 있어야 하며 기본 백업 저장소는 pv-pool 유형이어야 합니다.

(BZ#2242854)

PostgreSQL DB 암호가 더 이상 코어 및 엔드포인트 로그에 일반 텍스트로 표시되지 않음

이전에는 noobaa-core의 내부 Postgresql 클라이언트에서 로그에 연결 매개변수 오브젝트를 출력했으며 이 오브젝트에 Postgresql DB에 연결하기 위한 암호가 포함되어 있었습니다.

이번 수정을 통해 로그에 출력되는 연결 오브젝트에서 암호 정보가 생략되고 로그에 대한 메시지에는 중요하지 않은 연결 세부 정보만 포함됩니다.

(BZ#2240778)

CSI CephFS 및 RBD 소유자 Pod는 업그레이드 후 이전 cephcsi 이미지를 더 이상 사용하지 않음

이전 버전에서는 CSI CephFS 및 RBD 소유자 Pod를 업그레이드한 후 이전 cephcsi 이미지를 사용했기 때문에 업데이트되지 않았습니다.

이번 수정으로 CSI CephFS 및 RBD 홀더의 daemonset 오브젝트도 업그레이드되고 CSI 소유자 Pod에서도 최신 cephcsi 이미지를 사용합니다.

(BZ#2219536)

보다 안정적이고 제어된 재동기화 프로세스

이전에는 resync 명령이 효과적으로 트리거되지 않아 문제 및 이미지 미러링을 비활성화할 수 없었습니다. CephCSI는 예측할 수 없는 상태 변경으로 인해 신뢰할 수 없는 재동기화 명령을 발행하기 위해 이미지 미러 상태에 종속되어 있었기 때문입니다.

이번 수정을 통해 볼륨이 데모되면 CephCSI에서 이미지 생성 타임 스탬프를 저장합니다. resync 명령이 발행되면 CephCSI는 저장된 타임스탬프와 현재 생성 타임스탬프를 비교하고 타임스탬프가 일치하는 경우에만 다시 동기화됩니다. 또한 CephCSI는 이미지 상태 및 마지막 스냅샷 타임스탬프를 검사하여 재동기화가 필요한지 또는 오류 메시지를 표시할 필요가 있는지 확인합니다. 이로 인해 보다 안정적이고 제어된 재동기화 프로세스가 생성됩니다.

(BZ#2165941)

S3 클라이언트가 동일한 영역에서 RGW와 통신할 수 없기 때문에 더 이상 불필요한 네트워크 대기 시간이 없습니다.

이전에는 Ceph 오브젝트 저장소를 사용하고 다른 영역으로의 전송을 요청할 때 S3 클라이언트가 동일한 영역의 RGW와 통신할 수 없기 때문에 불필요한 네트워크 대기 시간이 있었습니다.

이번 수정으로 주석 "service.kubernetes.io/topology-mode"가 RGW 서비스에 추가되어 요청이 동일한 영역의 RGW 서버로 라우팅됩니다. 결과적으로 Pod가 가장 가까운 RGW 서비스로 라우팅됩니다.

(BZ#2209098)

볼륨 유형 드롭다운이 사용자 인터페이스에서 제거됨

이전에는 내부 OpenShift Data Foundation 설치의 경우 내부 설치에서 디스크가 SSD로 가정해야 하는 경우에도 사용자 인터페이스에 기존 클러스터의 볼륨 유형 드롭다운에 HDD, SSD 또는 둘 다 표시되었습니다.

이번 수정을 통해 볼륨 유형 드롭다운이 사용자 인터페이스에서 제거되고 항상 SSD라고 가정합니다.

(BZ#2239622)

OpenShift Data Foundation Topology rook-ceph-operator 배포에서 올바른 리소스 표시

이전에는 CSI Pod 및 기타 Pod의 소유자 참조가 rook-ceph-operator로 설정되어 이러한 Pod가 배포의 일부로 표시되었습니다.

이번 수정을 통해 매핑 Pod 접근 방식이 축소되지 않고 top down으로 변경되어 배포와 관련된 Pod만 표시됩니다.

(BZ#2209251)

CSS 속성은 리소스 목록의 높이를 창 크기 변경으로 동적으로 조정하도록 설정됩니다.

이전에는 CSS 속성이 사이드바에 제대로 적용되지 않았기 때문에 토폴로지 보기 리소스 목록의 사이드바가 창 크기에 따라 조정되지 않았습니다.

이번 수정을 통해 리소스 목록의 높이를 전체 화면과 일반 화면 모드 모두 창 크기 변경 사항에 맞게 동적으로 조정하도록 CSS 속성이 설정됩니다.

(BZ#2209258)

LSO에서 기본 스토리지 클래스로 이동할 때 용량 작업이 더 이상 실패하지 않음

이전 버전에서는 확장의 PV(영구 볼륨)가 올바르게 생성되지 않았기 때문에 LSO에서 기본 스토리지 클래스로 이동할 때 실패한 용량 작업이 실패했습니다.

이번 수정을 통해 LSO 기반 스토리지 클래스를 사용하여 스토리지 클러스터를 처음 생성할 때 non-LSO 스토리지 클래스를 사용하는 추가 용량 작업은 허용되지 않습니다.

(BZ#2213183)

OpenShift Data Foundation 토폴로지의 리소스 사용률이 메트릭과 일치

이전에는 노드 및 배포 리소스에 대한 사이드바에 사용된 지표 쿼리가 달랐기 때문에 OpenShift Data Foundation 토폴로지의 리소스 사용률이 메트릭과 일치하지 않았습니다.

이번 수정을 통해 지표 쿼리가 동일하고 결과적으로 두 위치에서 값이 동일합니다.

(BZ#2214033)

외부 모드의 토폴로지 보기가 비활성화됨

이전 버전에서는 토폴로지 보기에서 외부 모드가 지원되지 않으므로 토폴로지 보기에 외부 모드의 빈 화면이 표시되었습니다.

이번 수정을 통해 외부 모드가 비활성화되고 빈 화면 대신 메시지가 표시됩니다.

(BZ#2216707)

토폴로지에서 더 이상 모든 노드에서 rook-ceph-operator를 표시하지 않음

이전에는 토폴로지 보기에 Rook-Ceph Operator 배포가 실제로 관련되지 않은 여러 Pod의 소유자이므로 모든 노드에서 Rook-Ceph Operator 배포가 표시되었습니다.

이번 수정을 통해 토폴로지 보기에서 노드에 배포 메커니즘이 변경되어 Rook-Ceph Operator 배포가 하나의 노드에만 표시됩니다.

(BZ#2233027)

콘솔 사용자 인터페이스에서 OVN 대신 더 이상 SDN을 표시하지 않음

이전에는 OpenShift Container Platform이 SDN에서 OVN으로 이동하더라도 콘솔 사용자 인터페이스에 OVN 대신 SDN이 표시되었습니다.

이번 수정으로 텍스트가 SDN에서 OVN으로 변경되었으며 결과적으로 네트워크 관리 텍스트에 OVN이 표시됩니다.

(BZ#2233731)

리소스 이름은 규칙을 따라야 합니다. "시작하고 소문자로 종료"하거나 regex에서 오류를 반환합니다.

이전 버전에서는 오브젝트 버킷 클레임의 입력 이름(OBC), 백업 저장소, 차단 풀, 네임스페이스 저장소 및 버킷 클래스에 대한 잘못된 regex 검증으로 인해 이름 시작 시 기호 또는 대문자를 입력할 때 규칙 "시작 및 소문자로 종료"가 위반되었습니다.

이번 릴리스에서는 문제가 해결되었으며 리소스 이름이 규칙을 따르지 않으면 "시작하고 소문자 또는 숫자로 끝나기", regex에서 오류를 반환합니다.

(BZ#2193109)

ODF 모니터링에 더 이상 메트릭 값이 누락되지 않음

이전에는 ceph-exporter의 서비스 모니터에 대한 포트가 누락되었습니다. 즉 Ceph 데몬 성능 지표가 누락되었습니다.

이번 수정으로 ceph-exporter 서비스 모니터의 포트가 추가되어 prometheus에 Ceph 데몬 성능 지표가 표시됩니다.

(BZ#2221488)

네트워크 문제가 있는 경우 OSD Pod가 더 이상 계속 실행되지 않음

이전에는 OSD Pod가 네트워크 문제로 인해 Fapping을 시작한 경우 계속 해제되었습니다. 이는 시스템에 부정적인 영향을 미칩니다.

이번 수정을 통해 특정 시간 후에 OSD Pod를 끊는 것으로 표시되고 더 이상 시스템에 영향을 미치지 않습니다.

(BZ#2223959)

MDS는 더 이상 불필요하게 다시 시작되지 않습니다.

이전에는 ceph fs 덤프를 확인하지 않고 활성 프로브가 MDS를 다시 시작했기 때문에 MDS Pod가 불필요하게 다시 시작되었습니다.

이번 수정으로 활성 프로브는 ceph fs dump 에서 MDS를 모니터링하고 MDS가 덤프 출력에 누락된 경우에만 MDS를 다시 시작합니다.

(BZ#2234377)

장애 조치 작업에서는 RPC 오류가 여전히 사용 중인 Pod에서 RADOS 블록 장치 이미지 마운트에 실패했습니다.

재해 복구(DR) 보호 워크로드를 통해 실패하면 Pod에서 RADOS 블록 장치(RBD) 이미지가 여전히 사용 중인 것으로 보고되는 장애 조치 클러스터의 볼륨을 사용할 수 있습니다. 이렇게 하면 Pod가 오랜 기간(최대 몇 시간) 동안 시작되지 않습니다.

(BZ#2007376)

관리 클러스터의 애플리케이션 네임스페이스 생성

애플리케이션 네임스페이스는 재해 복구(DR) 관련 사전 배포 작업을 위해 RHACM 관리 클러스터에 있어야 하므로 RHACM 허브 클러스터에 애플리케이션을 배포할 때 미리 생성됩니다. 그러나 허브 클러스터에서 애플리케이션이 삭제되고 관리 클러스터에서 해당 네임스페이스가 삭제되면 관리 클러스터에서 다시 생성됩니다.

해결방법: openshift-dr 은 RHACM 허브에서 관리 클러스터 네임스페이스에서 네임스페이스 매니페스트 작업 리소스를 유지 관리합니다. 이러한 리소스는 애플리케이션을 삭제한 후 삭제해야 합니다. 예를 들어 클러스터 관리자는 허브 클러스터에서 다음 명령을 실행합니다. oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw.

(BZ#2059669)

클러스터가 스트레치 모드에 있을 때 Ceph df 에서 잘못된 MAX AVAIL 값을 보고합니다.

Red Hat Ceph Storage 클러스터의 crush 규칙에 "가져오기" 단계가 여러 개 있는 경우 ceph df 보고서에는 맵에 사용 가능한 잘못된 최대 크기가 표시됩니다. 이 문제는 향후 릴리스에서 해결될 예정입니다.

(BZ#2100920)

두 DRPC는 동일한 네임스페이스에서 생성된 모든 영구 볼륨 클레임을 보호합니다.

여러 재해 복구(DR) 보호 워크로드를 호스팅하는 네임스페이스는 spec.pvcSelector 필드를 사용하여 워크로드를 기반으로 PVC를 지정하고 분리하지 않는 허브 클러스터의 각 네임스페이스에 대해 네임스페이스 내의 모든 PVC(영구 볼륨 클레임)를 보호합니다.

그러면 여러 워크로드에서 DRPlacementControl spec.pvcSelector 와 일치하는 PVC가 생성됩니다. 또는 선택기가 모든 워크로드에서 누락된 경우 각 PVC를 여러 번 관리하고 개별 DRPlacementControl 작업을 기반으로 데이터 손상 또는 잘못된 작업을 유발하는 복제 관리입니다.

해결방법: 워크로드에 고유하게 속하는 라벨 PVC와 DRPlacementControl spec.pvcSelector 로 선택한 레이블을 사용하여 네임스페이스 내에서 PVC의 하위 집합을 보호하고 관리하는 DRPlacementControl을 분리합니다. 사용자 인터페이스를 사용하여 DRPlacementControl에 대해 spec.pvcSelector 필드를 지정할 수 없으므로 명령줄을 사용하여 이러한 애플리케이션에 대한 DRPlacementControl을 삭제하고 생성해야 합니다.

결과: PVC는 여러 DRPlacementControl 리소스에서 더 이상 관리되지 않으며 작업 및 데이터 불일치를 유발하지 않습니다.

(BZ#2111163)

MongoDB Pod는 cephrbd 볼륨의 데이터 읽기 오류로 인해 CrashLoopBackoff 에 있습니다.

다른 관리 클러스터의 OpenShift 프로젝트에는 지정된 UID 범위 및/또는 FSGroups 에서 특별히 다른 SCC(보안 컨텍스트 제약 조건)가 있습니다. 이로 인해 로그에 있는 파일 시스템 액세스 오류로 인해 특정 워크로드 Pod 및 컨테이너가 장애 조치(failover) 또는 재배치 작업을 시작하지 못합니다.

해결방법: 동일한 프로젝트 수준 SCC 라벨이 있는 모든 관리 클러스터에서 워크로드 프로젝트가 생성되도록 하여 실패한 경우 동일한 파일 시스템 컨텍스트를 사용하거나 재배치할 수 있습니다. Pod는 파일 시스템 관련 액세스 오류에서 더 이상DR 후 작업에 실패하지 않습니다.

(BZ#2114573)

애플리케이션이 재배치 중 재배치 상태로 유지됨

Multicloud Object Gateway를 사용하면 동일한 이름 또는 네임스페이스의 PV(영구 볼륨) 오브젝트를 동일한 경로의 S3 저장소에 추가할 수 있었습니다. 이로 인해 Ramen은 동일한 claimRef 를 가리키는 여러 버전을 감지했기 때문에 PV를 복원하지 않습니다.

해결방법: S3 CLI를 사용하거나 이에 상응하는 S3 저장소에서 중복 PV 오브젝트를 정리합니다. 타임스탬프가 장애 조치(failover) 또는 재배치 시간에 더 가깝게 있는 하나만 유지합니다.

결과: 복원 작업이 완료되고 장애 조치(failover) 또는 재배치 작업이 다음 단계로 진행됩니다.

(BZ#2120201)

삭제 시 재해 복구 워크로드가 유지됨

클러스터에서 워크로드를 삭제할 때 해당 Pod가 FailedKillPod 와 같은 이벤트로 종료되지 않을 수 있습니다. 이로 인해 PVC, VolumeReplication , VolumeReplication Group 과 같은 종속적인 DR 리소스를 가비지 수집 지연 또는 실패할 수 있습니다. 또한 오래된 리소스가 아직 가비지 수집되지 않은 경우 클러스터에 동일한 워크로드를 향후 배포하지 않습니다.

해결방법: Pod가 현재 실행 중이고 종료 상태로 중단된 작업자 노드를 재부팅합니다. 이로 인해 Pod가 성공적으로 종료되고 이후 관련 DR API 리소스도 가비지 수집됩니다.

(BZ#2159791)

관리 클러스터가 다른 버전의 OpenShift Container Platform 및 OpenShift Data Foundation에 있는 경우 애플리케이션 페일오버가 FailingOver 상태로 중단됨

OpenShift Data Foundation 4.14를 사용한 재해 복구 솔루션은 PV(영구 볼륨) 데이터 외에도 PVC(영구 볼륨 클레임) 데이터를 보호하고 복원합니다. 기본 클러스터가 이전 OpenShift Data Foundation 버전에 있고 대상 클러스터가 4.14로 업데이트되면 S3 저장소에 PVC 데이터가 없으므로 페일오버가 중단됩니다.

해결방법: 재해 복구 클러스터를 업그레이드할 때 먼저 기본 클러스터를 업그레이드한 다음 업그레이드 후 단계를 실행해야 합니다.

(BZ#2214306)

DRPolicy가 동일한 네임스페이스 아래의 여러 애플리케이션에 적용되면 볼륨 복제 그룹이 생성되지 않습니다.

네임스페이스의 다른 애플리케이션과 함께 배치되는 애플리케이션에 대해 DRPlacementControl(DRPC)이 생성되면 DRPC에 애플리케이션에 대해 설정된 라벨 선택기가 없습니다. 이후 라벨 선택기를 변경하면 OpenShift Data Foundation Hub 컨트롤러의 검증 승인 Webhook가 변경 사항을 거부합니다.

해결방법: 승인 Webhook가 변경되어 이러한 변경을 허용하면 DRPC validatingwebhookconfigurations 를 패치하여 Webhook를 제거할 수 있습니다.

$ oc patch validatingwebhookconfigurations vdrplacementcontrol.kb.io-lq2kz --type=json --patch='[{"op": "remove", "path": "/webhooks"}]'

(BZ#2210762)

FailingOver에서 c1에서 c2 클러스터로 앱 장애 조치

s3 저장소 구성 오류로 인해 데이터를 s3 저장소에 업로드하지 않을 때 장애 조치(failover) 작업은 비활성화되지 않습니다. 즉, 장애 조치 중에 장애 조치(failover) 클러스터에서 클러스터 데이터를 사용할 수 없습니다. 따라서 장애 조치를 완료할 수 없습니다.

해결방법: 초기 배포 후 ramen 로그를 검사하여 s3 구성 오류가 보고되지 않도록 합니다.

$ oc get drpc -o yaml

(BZ#2248723)

허브 복구 후 데이터 손실의 잠재적 위험

고립된 리소스를 정리하도록 설계된 제거 루틴으로 인해 허브 복구 후 잠재적인 데이터 손실 위험이 존재합니다. 이 루틴은 AppliedManifestWorks 인스턴스가 컬렉션에 대한 해당 ManifestWorks 가 없는 인스턴스를 식별하고 표시합니다. 하드 코딩된 유예 기간이 1시간 제공됩니다. 이 기간이 지나면 AppliedManifestWork 와 연결된 모든 리소스가 가비지 수집의 대상이 됩니다.

허브 클러스터가 초기 1시간 이내에 해당 ManifestWorks 를 다시 생성하지 못하면 데이터 손실이 발생할 수 있습니다. 이는 데이터 손실 위험을 최소화하기 위해 ManifestWorks 후 복구의 재생성을 방지할 수 있는 모든 문제를 신속하게 해결하는 것이 중요합니다.

(BZ-2252933)

CephFS에서 클러스터 확장의 성능 저하

많은 작은 메타데이터 작업이 있는 워크로드는 다중 사이트 Data Foundation 클러스터에서 메타데이터 서버(MDS)를 임의로 배치하기 때문에 성능이 저하될 수 있습니다.

(BZ#1982116)

SELinux의 레이블이 매우 많은 파일의 레이블 지정 문제

Red Hat OpenShift Container Platform의 Pod에 볼륨을 연결할 때 Pod가 시작되지 않거나 시작하는 데 과도한 시간이 걸리는 경우가 있습니다. 이 동작은 일반적이며 Kubelet에서 SELinux 재레이블을 처리하는 방법과 관련이 있습니다. 이 문제는 파일 수가 매우 높은 파일 시스템 기반 볼륨에서 관찰됩니다. OpenShift Data Foundation에서는 매우 많은 파일과 함께 CephFS 기반 볼륨을 사용할 때 문제가 발생합니다. 이 문제를 해결하는 방법은 다양합니다. 비즈니스 요구에 따라 지식 베이스 솔루션 https://access.redhat.com/solutions/6221251 에서 해결 방법 중 하나를 선택할 수 있습니다.

(Jira#3327)

충돌 또는 종료 테스트가 실행된 후에는 Ceph에 액세스할 수 없습니다.

스트레치 클러스터에서 모니터가 개선되고 다른 모니터가 MonitorMap 또는 OSDMap 과 같은 최신 정보를 수신하기 위해 모니터가 업데이트되면 프로빙 단계에 있을 때 stretch_mode 에 들어갈 수 없습니다. 이렇게 하면 선택자의 disallowed_leaders 목록을 올바르게 설정할 수 없습니다.

재발성 모니터가 실제로 가장 좋은 점수를 가지고 있다고 가정하면 현재 선택 라운드의 리더가되는 것이 가장 적합한 것으로 생각하고 모니터의 선택 단계가 유지되며 허용되지 않은_leaders 목록으로 인해 비활성화 된 모니터에 의해 거부되고 계속 거부 될 것입니다. 이로 인해 모니터가 선택 해제되고 Ceph가 결국 응답하지 않습니다.

이 문제를 해결하려면 선택 및 Ceph가 응답하지 않는 경우 명령을 사용하여 각 모니터의 연결 점수를 재설정합니다.

`ceph daemon mon.{name} connection scores reset`

이 기능이 작동하지 않으면 모니터를 하나씩 다시 시작합니다. 그러면 선택 사항이 해제되고 모니터는 리더를 선택하고 쿼럼을 형성하며 Ceph가 다시 응답 상태가 됩니다.

(BZ#2241937)

워크로드 배포 후 Ceph에서 활성 mgr을 보고하지 않음

워크로드 배포 후 Ceph 관리자는 MON에 대한 연결이 끊어지거나 활성 상태 프로브에 응답할 수 없습니다.

이로 인해 ODF 클러스터 상태가 "활성 mgr"이 있다고 보고합니다. 이로 인해 Ceph 관리자를 사용하여 요청 처리가 실패하는 여러 작업이 발생합니다. 예를 들어 볼륨 프로비저닝, CephFS 스냅샷 생성 등입니다.

ODF 클러스터의 상태를 확인하려면 oc get cephcluster -n openshift-storage 명령을 사용합니다. 상태 출력에서 클러스터에 이 문제가 있는 경우 status.ceph.details.MGR_DOWN 필드에 "활성 mgr" 메시지가 표시됩니다.

이 문제를 해결하려면 다음 명령을 사용하여 Ceph 관리자 Pod를 다시 시작하십시오.

# oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=0

# oc scale deployment -n openshift-storage rook-ceph-mgr-a --replicas=1

이러한 명령을 실행한 후 ODF 클러스터 상태는 정상 클러스터를 보고하고 MGR_DOWN 과 관련된 경고 또는 오류가 표시되지 않습니다.

(BZ#2244873)

StorageCluster에서 사용자 지정 deviceClass를 사용하는 경우 CephBlockPool 생성이 실패합니다.

알려진 문제로 인해 StorageCluster에서 사용자 지정 deviceClass를 사용하면 CephBlockPool 생성이 실패합니다.

(BZ#2248487)

NodeStageVolume RPC 호출이 누락되어 새 Pod가 Running 상태가 되지 않음

NodeStageVolume RPC 호출은 일부 Pod가 Running 상태가 되는 것을 차단하는 문제가 발생하지 않습니다. 새 Pod는 영구적으로 보류 중 상태로 유지됩니다.

이 문제를 해결하려면 영향을 받는 모든 Pod를 한 번에 축소하거나 노드 재부팅을 수행합니다. 해결 방법을 적용한 후 모든 Pod가 Running 상태가 됩니다.

(BZ#2244353)

백업이 데이터 전송 실패

백업이 데이터를 전송하지 못하고 스냅샷 PVC는 Pending 상태로 유지되는 경우도 있습니다.

(BZ#2248117)