7장. 확인된 문제

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

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

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

$ 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#2128860)

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

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

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

(BZ#2081855)

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

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

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

(BZ#2159791)

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)

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

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

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

(BZ#2215462)

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

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

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

$ oc get drpc -o yaml

(BZ#2248723)

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

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

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

지역 DR Cephfs 기반 애플리케이션 페일오버에서 서브스크립션에 대한 경고 표시

애플리케이션이 장애 발생 또는 재배치된 후 hub subscriptions에 "Some resources failed to deploy."라는 오류가 표시됩니다. 세부 정보를 보려면 상태 YAML 보기 링크를 사용합니다. 이는 CephFS를 백업 스토리지 프로비전 프로그램으로 사용하는 애플리케이션 PVC(영구 볼륨 클레임)가 RHACM(Red Hat Advanced Cluster Management for Kubernetes) 서브스크립션을 사용하여 배포되며 DR 보호는 해당 DR 컨트롤러에서 소유하기 때문입니다.

해결방법: 서브스크립션 상태의 오류를 수정하는 해결 방법이 없습니다. 그러나 배포에 실패한 서브스크립션 리소스는 PVC인지 확인할 수 있습니다. 이렇게 하면 다른 리소스에 문제가 발생하지 않습니다. 배포에 실패한 서브스크립션의 유일한 리소스가 DR protected인 경우 오류를 무시할 수 있습니다.

(BZ-2264445)

disabled PeerReady 플래그를 사용하면 action을 Cryostat로 변경할 수 없습니다.

DR 컨트롤러는 필요에 따라 전체 조정을 실행합니다. 클러스터에 액세스할 수 없게 되면 DR 컨트롤러에서 온전성 검사를 수행합니다. 워크로드가 이미 재배치된 경우 이 정상 검사로 인해 워크로드와 관련된 PeerReady 플래그가 비활성화되고 클러스터가 오프라인 상태가 되기 때문에 온전성 검사가 완료되지 않습니다. 결과적으로 비활성화된 PeerReady 플래그를 사용하면 작업을 Cryostat로 변경할 수 없습니다.

해결방법: 명령줄 인터페이스를 사용하여 비활성화된 PeerReady 플래그에도 불구하고 DR 작업을 Cryostat로 변경합니다.

(BZ-2264765)

확장 클러스터의 두 데이터 센터 간에 연결이 끊어지면 Ceph에 액세스할 수 없게 되고 IO가 일시 중지됩니다.

두 데이터 센터가 서로 연결되어 있지만 Arbiter 노드에 여전히 연결되어 있는 경우 선택 논리에 결함이 있어 모니터 간에 무한 선택을 할 수 있습니다. 결과적으로 모니터는 리더를 선택할 수 없으며 Ceph 클러스터를 사용할 수 없게 됩니다. 또한 연결 손실 중에 IO가 일시 중지됩니다.

해결방법: 모니터가 쿼럼이 없는 데이터 센터 중 하나에서 모니터를 종료하고( ceph -s 명령을 실행하여 이를 찾을 수 있음) 나머지 모니터의 연결 점수를 재설정합니다.

결과적으로 모니터는 쿼럼을 형성하고 Ceph를 다시 사용할 수 있게 되고 IO가 다시 시작됩니다.

(파트너 BZ#2265992)

장애 조치(failover) 후 이전 기본 관리 클러스터를 복구한 후 ApplicationSet 워크로드에 대한 정리 및 데이터 동기화가 중단된 상태로 유지됩니다.

허브 클러스터가 실패하는 경우 관리 클러스터에 대한 ApplicationSet 기반 워크로드 배포는 가비지 수집되지 않습니다. 워크로드가 남아 있는 관리형 클러스터로 장애 조치되는 동안 대기 허브 클러스터로 복구됩니다. 워크로드가 페일오버된 클러스터에서 새 복구 대기 허브에 다시 참여합니다.

재해 복구(DR) 보호되고 지역 DRPolicy에서 VolumeSynchronizationDelay 경고가 실행되는 ApplicationSet이 시작됩니다. 두 클러스터 간에 데이터가 동기화되지 않아 DR 보호 워크로드를 피어 클러스터로 장애 조치하거나 피어 클러스터로 재배치할 수 없습니다.

해결방법은 OpenShift 워크로드용 OpenShift Data Foundation 재해 복구 구성의 Regional-DR 문제 해결 섹션을 참조하십시오.

(BZ#2268594)