4.12 릴리스 노트

지역 재해 복구 (Regional-DR)

regional-DR 솔루션은 블록 볼륨, 비동기 복제에 대한 자동 보호 기능을 제공하며 지리적 위치에서 재해가 발생할 때 비즈니스 기능을 보호합니다. 퍼블릭 클라우드에서는 지역 장애로부터 보호하는 것과 유사합니다. 자세한 내용은 OpenShift Data Foundation의 계획 가이드 및 지역-DR 솔루션을 참조하십시오.

Red Hat Advanced Cluster Management 콘솔의 다중 클러스터 모니터링

멀티 클러스터 모니터링은 여러 클러스터에 분배된 스토리지 상태 및 용량에 대한 단일 단순화 보기입니다. 이 멀티 클러스터 모니터링을 사용하면 RHACM(Red Hat Advanced Cluster Management) 사용자 인터페이스에서 스토리지 용량을 관리하고 OpenShift Data Foundation 클러스터를 모니터링할 수 있습니다. 이 모니터링 기능은 DR 및 비DR 클러스터에 모두 적용됩니다. 자세한 내용은 다중 클러스터 스토리지 상태 모니터링 을 참조하십시오.

CephFS 볼륨에 대해 regional-DR을 비동기식으로 사용 가능

regional-DR 솔루션은 이제 Ceph RBD 볼륨에서 OpenShift Data Foundation의 OpenShift Data Foundation 환경과 유사한 OpenShift 콘솔을 사용하여 CephFS 볼륨과 같은 regional-DR 작업을 추가하여 고객 DR 워크로드 기능을 확장합니다. 자세한 내용은 계획 가이드 및 지역-DR 솔루션 가이드를 참조하십시오.

Async 복제는 더 이상 0으로 설정할 수 없습니다.

이전에는 동기화 일정 의 값을 입력할 수 있었습니다. 이로 인해 async 복제를 0 으로 설정할 수 있어 오류가 발생했습니다. 이번 업데이트를 통해 1보다 낮은 값을 허용하지 않는 숫자 입력이 도입되었습니다. 이제 async 복제가 올바르게 작동합니다.

(BZ#2114501)

이제 Application이 Pod 및 PVC를 올바르게 삭제

이전에는 RHACM 콘솔에서 애플리케이션을 삭제할 때 DRPC가 삭제되지 않았습니다. DRPC를 삭제하지 않으면 VRG뿐만 아니라 VRG도 삭제되지 않습니다. VRG/VR이 삭제되지 않으면 PVC 종료자 목록이 정리되지 않으므로 PVC가 Terminating 상태로 유지됩니다.

이번 업데이트를 통해 RHACM 콘솔에서 애플리케이션을 삭제하면 관리 클러스터에서 필요한 종속 DRPC 및 관련 리소스가 삭제되어 필요한 가비지 수집과 PVC가 확보됩니다.

(BZ#2108716)

워크로드가 중단되거나 재배치되지 않는 경우 내부 VolumeReplicaitonGroup 리소스를 삭제하면 더 이상 오류가 발생하지 않습니다.

재해 복구(DR) 조정 프로그램의 버그로 인해 워크로드가 장애 발생하거나 재배치되지 않는 관리형 클러스터에서 내부 VolumeReplicaitonGroup 리소스를 삭제하는 동안 PVC(영구 볼륨 클레임)가 보호되지 않았습니다. 결과 정리 작업이 완료되지 않았으며 애플리케이션의 DRPlacementControl 에서 False 로 PeerReady 조건을 보고합니다. 이는 DRPlacementControl 리소스에서 PeerReady 조건을 False 로 보고했기 때문에 실패했거나 재배치할 수 없는 애플리케이션을 다시 의미합니다.

이번 업데이트를 통해 내부 VolumeReplicationGroup 리소스를 삭제하는 동안 PVC가 다시 보호되지 않아 정지된 정리 문제가 발생하지 않습니다. 이로 인해 DRPlacementControl 에서 PeerReady 를 True 로 보고한 후 정리가 자동으로 완료됩니다.

(BZ#2116605)

StorageClass 생성을 기다리는 동안 스토리지 클러스터 가 더 이상 Error 상태가 되지 않음

Red Hat OpenShift Data Foundation StorageCluster 가 생성되면 StorageClass 를 생성하기 전에 기본 풀이 생성될 때까지 기다립니다. 이 시간 동안 클러스터는 풀이 준비될 때까지 조정 요청에 대한 오류를 반환합니다. 이 오류로 인해 StorageCluster 단계가 Error 로 설정됩니다. 이번 업데이트를 통해 풀 생성 중에 이 오류가 발생하고 StorageCluster 의 단계가 진행 중입니다.

(BZ#2004027)

RHCS 5.1에서 이후 버전으로 업데이트할 때 버킷 메타데이터에는 더 이상 문제가 없습니다.

RHCS(Red Hat Ceph Storage) 버전 5.1과 함께 제공되는 RADOS 게이트웨이(RGW)에는 다중 사이트 복제 설정에서 동적 버킷 인덱스 재조정을 위한 not-yet-GA 지원과 관련된 논리가 포함되어 있습니다. 이 논리는 RHCS 5.2에서 의도적으로 제거되었습니다. RHCS 5.1로 업그레이드한 사이트는 RHCS 5.1의 버킷 메타데이터 처리가 호환되지 않기 때문에 RHCS 5.2로 업그레이드할 수 없습니다. 이 상황은 이제 RHCS 5.3으로 업그레이드하여 해결되었습니다. 결과적으로 RHCS 5.3은 5.1을 포함한 모든 이전 버전에서 생성된 버킷에서 작동할 수 있습니다.

(BZ#2115645)

ODF Operator가 설치되면 더 이상 Pod 보안 Violation 경고가 없습니다.

OpenShift Data Foundation 버전 4.11은 권한 있는 Pod 실행에 대한 경고를 제공하는 새로운 POD Security Admission 표준을 도입했습니다. ODF Operator 배포에서는 권한이 필요한 몇 가지 Pod를 사용합니다. 이로 인해 ODF Operator가 배포된 후 Pod Security Violation 경고가 실행되기 시작했습니다.

이번 릴리스에서는 관련 Pod 보안 Admission 표준에 대해 OLM에서 openshift-* 접두사가 붙은 Namespace에 자동으로 레이블을 지정합니다.

(BZ#2110628)

장애 조치(failover) 작업은 RPC 오류가 계속 사용 중인 Pod에서 RADOS 블록 장치 이미지 마운트 실패 보고

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

(BZ#2007376)

장애 조치(failover) 작업은 RPC 오류 fsck가 있는 Pod에서 RADOS 블록 장치 이미지 마운트 실패 보고

재해 복구(DR) 보호 워크로드를 통해 실패하면 볼륨에 파일 시스템 일관성 검사(fsck) 오류가 있는 볼륨 마운트 오류로 인해 Pod가 시작되지 않을 수 있습니다. 이로 인해 워크로드가 장애 조치(failover) 클러스터로 장애 조치되지 않습니다.

(BZ#2021460)

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

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

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

(BZ#2059669)

일부 이미지에 대해 RBD 미러 예약이 중지됨

Ceph 관리자 데몬은 다양한 이유로 인해 차단됩니다. 이로 인해 예약된 RBD 미러 스냅샷이 이미지가 기본인 클러스터에서 트리거됩니다. 미러가 활성화된 모든 RBD 이미지(하위 DR 보호)는 rbd 미러 스냅샷 일정 상태 -p ocs-storagecluster-cephblockpool을 사용하여 검사할 때 일정을 나열하지 않으므로 피어 사이트에 적극적으로 미러링되지 않습니다.

해결방법: 이미지가 기본인 관리 클러스터에서 Ceph 관리자 배포를 다시 시작하여 현재 실행 중인 인스턴스에 대한 blocklist를 극복하기 위해 현재 실행 중인 인스턴스에 대한 blocklist를 제거한 다음 나중에 다음과 같이 ceph Manager 배포를 확장할 수 있습니다.

oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=0
oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=1

$ oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=0
$ oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=1

결과: DR이 활성화되어 있고 rbd 미러 스냅샷 일정을 사용하여 검사할 때 미러링 일정의 기본으로 표시되는 이미지 -p ocs-storagecluster-cephblockpool

(BZ#2067095)

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

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

(BZ#2100920)

Ceph는 Globalnet에서 할당한 글로벌 IP를 인식하지 않습니다.

Ceph는 Globalnet에서 할당한 글로벌 IP를 인식하지 않으므로 Globalnet을 사용하여 중복 서비스 CIDR이 있는 클러스터 간에 재해 복구 솔루션을 구성할 수 없습니다. 이 때문에 service CIDR 이 겹치면 재해 복구 솔루션이 작동하지 않습니다.

(BZ#2102397)

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

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

이로 인해 여러 워크로드에서 DRPlacementControl spec.pvcSelector 와 일치하는 PVC가 생성됩니다. 또는 선택기가 모든 워크로드에서 누락된 경우 복제 관리를 통해 각 PVC를 여러 번 관리하고 개별 DRPlacementControl 작업을 기반으로 데이터 손상 또는 유효하지 않은 작업을 유발할 수 있습니다.

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

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

(BZ#2111163)

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

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

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

(BZ#2114573)

재배치 중 애플리케이션이 재배치 중 정지됨

멀티클라우드 오브젝트 게이트웨이는 동일한 이름 또는 네임스페이스의 여러 PV(영구 볼륨) 오브젝트를 동일한 경로의 S3 저장소에 추가할 수 있었습니다. 이로 인해 Ramen은 동일한 claimRef 를 가리키는 여러 버전을 탐지했기 때문에 PV를 복원하지 않습니다.

해결방법: S3 CLI를 사용하여 S3 저장소에서 중복된 PV 오브젝트를 정리합니다. 타임스탬프가 있는 경우에만 장애 조치(failover) 또는 재배치 시간에 가까운 상태로 두십시오.

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

(BZ#2120201)

영역이 다운되면 애플리케이션이 FailingOver 상태로 유지됨

장애 조치 또는 재배치 시 s3 저장소에 연결할 수 없는 경우 장애 조치(failover) 또는 재배치 프로세스가 중단됩니다. DR 로그에 S3 저장소에 연결할 수 없음을 나타내는 경우 문제 해결 및 s3 저장소 작업을 수행하면 DR이 장애 조치 또는 재배치 작업을 진행할 수 있습니다.

(BZ#2121680)

PeerReady 상태는 워크로드가 장애 조치되거나 피어 클러스터로 재배치될 때 클러스터가 실패하거나 재배치될 때까지 true 로 설정됩니다.

재해 복구(DR) 작업이 시작된 후 워크로드가 장애 조치되거나 피어 클러스터로 재배치될 때 PeerReady 조건이 처음에 true 로 설정됩니다. 그런 다음 향후 작업을 위해 클러스터가 실패한 위치에서 실패하거나 재배치될 때까지 false 로 설정됩니다. 향후 작업에 대한 DRPlacementControl 상태 조건을 살펴보면 피어가 동일한 작업을 수행할 준비가 되어 있으므로 이 중간 PeerReady 상태를 인식할 수 있습니다. 이로 인해 작업이 보류 중이거나 실패하게 되며 복구하기 위해 사용자 개입이 필요할 수 있습니다.

해결방법: 작업을 수행하기 전에 Available 및 PeerReady 상태를 모두 테스트합니다. 워크로드의 정상적인 DR 상태에 대해 둘 다 true 여야 합니다. 두 상태가 모두 true인 경우 수행된 작업으로 인해 요청된 작업이 진행 중입니다.

(BZ#2138855)

재해 복구 워크로드는 삭제해도 유지됨

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

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

(BZ#2159791)

Blocklisting으로 인해 Pod 상태가 오류 상태가 될 수 있습니다.

네트워크 문제 또는 과도하게 과부하되거나 불균형된 클러스터로 인한 차단 목록(Trendlisting)으로 인해 대량의 대기 시간이 급증하게 됩니다. 이로 인해 Pod가 Error: relabel failed /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io-86e7da91-와 함께 중지되었습니다. 29f9-4418-80ae7610ae7610bb613/mount: lsetxattr /var/lib/kubelet/pods/cb27938e-f66f-401d-85f-401d-85f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91 -29f9-4418-80ae7610bb613/mount/#ib_16384_0.dblwr: 읽기 전용 파일 시스템.

해결방법: 다음 단계에 따라 이러한 Pod가 예약되고 실패하는 노드를 다시 부팅합니다.

(BZ#2094320)

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)

업그레이드 후 OpenShift Data Foundation 대시보드 충돌

OpenShift Container Platform 및 OpenShift Data Foundation이 업그레이드되면 대시보드 링크를 클릭하면 Storage 섹션의 Data Foundation 대시보드가 "404: Page not found" 오류로 충돌합니다. 이는 콘솔을 새로 고치는 팝업이 나타나지 않기 때문입니다.

해결방법: 콘솔을 하드 새로 고침을 수행합니다. 대시보드를 다시 가져오고 더 이상 충돌하지 않습니다.

(BZ#2157876)