7장. 확인된 문제

장애 조치(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

결과: 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)