7장. 확인된 문제
이 섹션에서는 Red Hat OpenShift Data Foundation 4.16의 알려진 문제에 대해 설명합니다.
7.1. 재해 복구
관리 클러스터의 애플리케이션 네임스페이스 생성
애플리케이션 네임스페이스는 재해 복구(DR) 관련 사전 배포 작업을 위해 RHACM 관리 클러스터에 있어야 하므로 RHACM 허브 클러스터에 애플리케이션을 배포할 때 미리 생성됩니다. 그러나 허브 클러스터에서 애플리케이션이 삭제되고 관리 클러스터에서 해당 네임스페이스가 삭제되면 관리 클러스터에서 다시 생성됩니다.
해결방법:
openshift-dr은 RHACM 허브에서 관리 클러스터 네임스페이스에서 네임스페이스매니페스트 작업리소스를 유지 관리합니다. 이러한 리소스는 애플리케이션을 삭제한 후 삭제해야 합니다. 예를 들어 클러스터 관리자는 hub 클러스터에서 다음 명령을 실행합니다.$ oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw
클러스터가 스트레치 모드에 있을 때 Ceph
df에서 잘못된 MAX AVAIL 값을 보고합니다.Red Hat Ceph Storage 클러스터의 crush 규칙에 "가져오기" 단계가 여러 개 있는 경우
ceph df보고서에는 맵에 사용 가능한 잘못된 최대 크기가 표시됩니다. 이 문제는 향후 릴리스에서 해결될 예정입니다.
두 DRPC는 동일한 네임스페이스에서 생성된 모든 영구 볼륨 클레임을 보호합니다.
여러 재해 복구(DR) 보호 워크로드를 호스팅하는 네임스페이스는
spec.pvcSelector필드를 사용하여 워크로드를 기반으로 PVC를 지정하고 분리하지 않는 허브 클러스터의 각 네임스페이스에 대해 네임스페이스 내의 모든 PVC(영구 볼륨 클레임)를 보호합니다.이로 인해 여러 워크로드에서 DRPlacementControl
spec.pvcSelector와 일치하는 PVC가 생성됩니다. 또는 선택기가 모든 워크로드에서 누락된 경우 각 PVC를 여러 번 관리하고 개별 DRPlacementControl 작업을 기반으로 데이터 손상 또는 잘못된 작업을 유발하는 복제 관리입니다.해결방법: 워크로드에 고유하게 속하는 라벨 PVC와 DRPlacementControl
spec.pvcSelector로 선택한 레이블을 사용하여 네임스페이스 내에서 PVC의 하위 집합을 보호하고 관리하는 DRPlacementControl을 분리합니다. 사용자 인터페이스를 사용하여 DRPlacementControl에 대해spec.pvcSelector필드를 지정할 수 없으므로 명령줄을 사용하여 이러한 애플리케이션에 대한 DRPlacementControl을 삭제하고 생성해야 합니다.결과: PVC는 여러 DRPlacementControl 리소스에서 더 이상 관리되지 않으며 작업 및 데이터 불일치를 유발하지 않습니다.
MongoDB Pod는
cephrbd볼륨의 데이터 읽기 오류로 인해CrashLoopBackoff에 있습니다.다른 관리 클러스터의 OpenShift 프로젝트에는 지정된 UID 범위 및/또는
FSGroups에서 특별히 다른 SCC(보안 컨텍스트 제약 조건)가 있습니다. 이로 인해 로그에 있는 파일 시스템 액세스 오류로 인해 특정 워크로드 Pod 및 컨테이너가 장애 조치(failover) 또는 재배치 작업을 시작하지 못합니다.해결방법: 동일한 프로젝트 수준 SCC 라벨이 있는 모든 관리 클러스터에서 워크로드 프로젝트가 생성되도록 하여 실패한 경우 동일한 파일 시스템 컨텍스트를 사용하거나 재배치할 수 있습니다. Pod는 파일 시스템 관련 액세스 오류에서 더 이상DR 후 작업에 실패하지 않습니다.
삭제 시 재해 복구 워크로드가 유지됨
클러스터에서 워크로드를 삭제할 때 해당 Pod가
FailedKillPod와 같은 이벤트로 종료되지 않을 수 있습니다. 이로 인해PVC, VolumeReplication ,VolumeReplicationGroup해결방법: Pod가 현재 실행 중이고 종료 상태로 중단된 작업자 노드를 재부팅합니다. 이로 인해 Pod가 성공적으로 종료되고 이후 관련 DR API 리소스도 가비지 수집됩니다.
지역 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인 경우 오류를 무시할 수 있습니다.
disabled
PeerReady플래그를 사용하면 action을 Cryostat로 변경할 수 없습니다.DR 컨트롤러는 필요에 따라 전체 조정을 실행합니다. 클러스터에 액세스할 수 없게 되면 DR 컨트롤러에서 온전성 검사를 수행합니다. 워크로드가 이미 재배치된 경우 이 정상 검사로 인해 워크로드와 관련된
PeerReady플래그가 비활성화되고 클러스터가 오프라인 상태가 되기 때문에 온전성 검사가 완료되지 않습니다. 결과적으로 비활성화된PeerReady플래그를 사용하면 작업을 Cryostat로 변경할 수 없습니다.해결방법: 명령줄 인터페이스를 사용하여 비활성화된
PeerReady플래그에도 불구하고 DR 작업을 Cryostat로 변경합니다.
확장 클러스터의 두 데이터 센터 간에 연결이 끊어지면 Ceph에 액세스할 수 없게 되고 IO가 일시 중지됩니다.
두 데이터 센터가 서로 연결되어 있지만 Arbiter 노드에 여전히 연결되어 있는 경우 선택 논리에 결함이 있어 모니터 간에 무한 선택을 할 수 있습니다. 결과적으로 모니터는 리더를 선택할 수 없으며 Ceph 클러스터를 사용할 수 없게 됩니다. 또한 연결 손실 중에 IO가 일시 중지됩니다.
해결방법: 모니터가 쿼럼이 없는 데이터 센터 중 하나에서 모니터를 종료하고(
ceph -s명령을 실행하여 이를 찾을 수 있음) 나머지 모니터의 연결 점수를 재설정합니다.결과적으로 모니터는 쿼럼을 형성하고 Ceph를 다시 사용할 수 있게 되고 IO가 다시 시작됩니다.
교체 클러스터에서 오래된 Ceph 풀 ID를 사용하는 경우 RBD 애플리케이션이 재배치되지 않음
새 피어 클러스터를 생성하기 전에 생성된 애플리케이션의 경우 피어 클러스터를 교체하면 CSI configmap에서 CephBlockPoolID의 매핑을 업데이트할 수 없기 때문에 RBD PVC를 마운트할 수 없습니다.
해결방법: 대체되지 않은 피어 클러스터에서 cephBlockPoolID의 매핑으로
rook-ceph-csi-mapping-configconfigmap을 업데이트합니다. 이를 통해 애플리케이션에 대한 RBD PVC를 마운트할 수 있습니다.
lastGroupSyncTime에 대한 정보는 사용 불가능한 관리형 클러스터에서 기본 제공되는 워크로드에 대한 허브 복구 후 손실됨이전에 관리 클러스터로 실패한 애플리케이션은
lastGroupSyncTime을 보고하지 않으므로VolumeSynchronizationDelay경고가 트리거됩니다. 이는 DRPolicy의 일부인 ACM 허브 및 관리 클러스터를 사용할 수 없는 경우 백업에서 새 ACM 허브 클러스터를 재구성하기 때문입니다.해결방법: 워크로드가 실패한 관리 클러스터를 사용할 수 없는 경우에도 남아 있는 관리 클러스터로 장애 조치할 수 있습니다.
MCO Operator는
veleroNamespaceSecretKeyRef및CACertificates필드를 조정합니다.OpenShift Data Foundation Operator가 업그레이드되면 Ramen 구성의
s3StoreProfiles의CACertificates및veleroNamespaceSecretKeyRef필드가 손실됩니다.해결방법: Ramen 구성에
CACertificates및veleroNamespaceSecretKeyRef필드의 사용자 지정 값이 있는 경우 업그레이드가 수행된 후 해당 사용자 지정 값을 설정합니다.
업그레이드 후 token-exchange-agent Pod의 불안정성
이전 배포 리소스가 제대로 정리되지 않으므로 관리 클러스터의
token-exchange-agentPod가 불안정합니다. 이로 인해 애플리케이션 장애 조치 작업이 실패할 수 있습니다.해결방법: ODF 4.16.0으로 업그레이드한 후 관리 클러스터에서 "token-exchange-agent" Pod가 불안정합니다.
결과: 해결방법을 따르는 경우 "token-exchange-agent" Pod가 안정화되고 장애 조치 작업이 예상대로 작동합니다.
virtualmachines.kubevirt.io리소스가 재배치 시 mac 할당 실패로 인해 복원되지 않음가상 머신을 기본 클러스터로 재배치하면 mac 주소를 사용할 수 없기 때문에 재배치를 완료하지 못할 수 있습니다. 이 문제는 가상 머신이 장애 조치(failover) 클러스터로 장애 조치(failover)할 때 기본 클러스터에서 완전히 정리되지 않은 경우 발생합니다.
워크로드를 재배치하기 전에 워크로드가 기본 클러스터에서 완전히 제거되었는지 확인합니다.
hub recovery, subscription app pods are not coming up after Cryostat
허브 복구 후 서브스크립션 애플리케이션 Pod는 기본에서 보조 관리형 클러스터로 장애 조치한 후 나타나지 않습니다. 관리 클러스터의
AppSub서브스크립션 리소스에서 RBAC 오류가 발생합니다. 이는 백업 및 복원 시나리오의 타이밍 문제로 인해 발생합니다. 각 관리 클러스터에서 application-manager Pod가 다시 시작되면 허브 서브스크립션 및 채널 리소스가 새 허브에서 다시 생성되지 않습니다. 결과적으로 하위AppSub구독 리소스가 오류와 함께 조정됩니다.해결방법:
다음 명령을 사용하여
appsub의 이름을 가져옵니다.% oc get appsub -n <namespace of sub app>
다음 명령을 사용하여 값이 있는 새 레이블을 허브의 AppSub에 추가합니다.
% oc edit appsub -n <appsub-namespace> <appsub>-subscription-1
하위 appsub 오류가 여전히 알 수 없는 인증서 문제를 표시하는 경우, 워크로드가 실패한 관리 클러스터에서 application-manager Pod를 다시 시작합니다.
% oc delete pods -n open-cluster-management-agent-addon application-manager-<>-<>
ReplicationDestination리소스가 아직 생성되지 않은 경우 장애 조치(failover) 프로세스가 실패합니다.LastGroupSyncTime이 업데이트되기 전에 사용자가 장애 조치(failover)를 시작하면 장애 조치(failover) 프로세스가 실패할 수 있습니다. 이 실패에는ReplicationDestination이 존재하지 않음을 나타내는 오류 메시지가 표시됩니다.해결방법:
허브 클러스터에서 VRG에 대한
ManifestWork를 편집합니다.매니페스트에서 다음 섹션을 삭제합니다.
/spec/workload/manifests/0/spec/volsync
변경 사항을 저장합니다.
이 해결 방법을 올바르게 적용하면 VRG에서
ReplicationDestination리소스를 사용하여 PVC를 복원하려고 합니다. PVC가 이미 존재하는 경우 애플리케이션은 그대로 사용합니다. PVC가 없으면 새 PVC가 생성됩니다.
