7장. 확인된 문제

장애 조치 작업에서는 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)