8장. 확인된 문제
이 섹션에서는 Red Hat OpenShift Data Foundation 4.18의 알려진 문제에 대해 설명합니다.
8.1. 재해 복구 링크 복사링크가 클립보드에 복사되었습니다!
노드 충돌로 인해 kubelet 서비스 오류가 발생하여 Data Foundation이 오류 상태가 됩니다.
OpenShift 클러스터에서 예기치 않은 노드가 충돌하면 노드가
NotReady상태에서 중단되고 스토리지 클러스터에 영향을 미칠 수 있습니다.해결방법:
보류 중인 CSR을 가져옵니다.
oc get csr | grep Pending
oc get csr | grep PendingCopy to Clipboard Copied! Toggle word wrap Toggle overflow 보류 중인 CSR을 승인합니다.
Approve the pending CSR
Approve the pending CSRCopy to Clipboard Copied! Toggle word wrap Toggle overflow
각 노드가 다운된 경우 CIDR 범위는
csiaddonsnode오브젝트에 유지되지 않습니다.노드가 다운되면 CIDR(Classless Inter-Domain Routing) 정보가
csiaddonsnode오브젝트에서 사라집니다. 이는 영향을 받는 노드를 펜싱해야 하는 경우 펜싱 메커니즘에 영향을 미칩니다.해결방법:
NetworkFenceClass오브젝트가 생성된 직후 CIDR 정보를 수집합니다.
노드를 교체한 후 새 mon Pod를 예약하지 못했습니다.
노드를 교체한 후 새
monpod가 새로 추가된 노드에 자체적으로 예약되지 않습니다. 결과적으로Pod가monPending상태로 유지되어 storagecluster 상태를 사용할 수 없게 됩니다.해결방법: 올바른
nodeSelector를 사용하여 새 mon 배포를 수동으로 업데이트합니다.
클러스터가 스트레치 모드에 있을 때 Ceph
df에서 잘못된MAX AVAIL값을 보고합니다.Red Hat Ceph Storage 클러스터의 CRUSH 규칙에 여러
가지 적용단계가 있는 경우ceph df보고서에는 연결된 풀에 사용 가능한 잘못된 최대 크기가 표시됩니다.
DRPC는 동일한 네임스페이스에서 생성된 모든 영구 볼륨 클레임을 보호합니다.
여러 재해 복구(DR) 보호 워크로드를 호스팅하는 네임스페이스는
spec.pvcSelector필드를 사용하여 워크로드에 따라 PVC를 지정하고 분리하지 않는 허브 클러스터의 각 DRPlacementControl 리소스에 대해 네임스페이스 내의 모든 PVC(영구 볼륨 클레임)를 보호합니다.이로 인해 여러 워크로드에서 DRPlacementControl
spec.pvcSelector와 일치하는 PVC가 생성됩니다. 또는 선택기가 모든 워크로드에서 누락된 경우 각 PVC를 여러 번 관리하고 개별 DRPlacementControl 작업을 기반으로 데이터 손상 또는 잘못된 작업을 유발하는 복제 관리입니다.해결방법: 워크로드에 고유하게 속하는 라벨 PVC와 DRPlacementControl
spec.pvcSelector로 선택한 레이블을 사용하여 네임스페이스 내에서 PVC의 하위 집합을 보호하고 관리하는 DRPlacementControl을 분리합니다. 사용자 인터페이스를 사용하여 DRPlacementControl에 대해spec.pvcSelector필드를 지정할 수 없으므로 명령줄을 사용하여 이러한 애플리케이션에 대한 DRPlacementControl을 삭제하고 생성해야 합니다.결과: PVC는 여러 DRPlacementControl 리소스에서 더 이상 관리되지 않으며 작업 및 데이터 불일치를 유발하지 않습니다.
disabled
PeerReady플래그를 사용하면 action을 Cryostat로 변경할 수 없습니다.DR 컨트롤러는 필요에 따라 전체 조정을 실행합니다. 클러스터에 액세스할 수 없게 되면 DR 컨트롤러에서 온전성 검사를 수행합니다. 워크로드가 이미 재배치된 경우 이 정상 검사로 인해 워크로드와 관련된
PeerReady플래그가 비활성화되고 클러스터가 오프라인 상태가 되기 때문에 온전성 검사가 완료되지 않습니다. 결과적으로 비활성화된PeerReady플래그를 사용하면 작업을 Cryostat로 변경할 수 없습니다.해결방법: 명령줄 인터페이스를 사용하여 비활성화된
PeerReady플래그에도 불구하고 DR 작업을 Cryostat로 변경합니다.
확장 클러스터의 두 데이터 센터 간에 연결이 끊어지면 Ceph에 액세스할 수 없게 되고 IO가 일시 중지됩니다.
두 데이터 센터가 서로 연결되어 있지만 Arbiter 노드에 연결되어 있는 경우 선택 논리에 결함이 있어 Ceph 모니터 간에 무한 선택이 발생합니다. 결과적으로 Monitor는 리더를 선택할 수 없으며 Ceph 클러스터를 사용할 수 없게 됩니다. 또한 연결 손실 중에 IO가 일시 중지됩니다.
해결방법: 영역 노드를 종료하여 하나의 데이터 영역의 모니터입니다. 또한 남아 있는 모니터 Pod의 연결 점수를 재설정할 수 있습니다.
결과적으로 모니터는 쿼럼을 형성하고 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필드의 사용자 지정 값이 있는 경우 업그레이드가 수행된 후 해당 사용자 지정 값을 설정합니다.
CephFS를 사용하여 검색된 앱의 경우 장애 조치 후 동기화 중지
CephFS 기반 워크로드의 경우 검색된 애플리케이션의 동기화가 페일오버 또는 재배치 후 어느 시점에서 중지될 수 있습니다. 이는
ReplicationSource상태에 보고된Permission Denied오류가 발생할 수 있습니다.해결방법:
검색되지 않은 애플리케이션의 경우
VolumeSnapshot를 삭제합니다.
oc delete volumesnapshot -n <vrg-namespace> <volumesnapshot-name>
$ oc delete volumesnapshot -n <vrg-namespace> <volumesnapshot-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 스냅샷 이름은 일반적으로 PVC 이름 뒤에 타임 스탬프로 시작됩니다.
volSync 작업을 삭제합니다.
oc delete job -n <vrg-namespace> <pvc-name>
$ oc delete job -n <vrg-namespace> <pvc-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업 이름은 PVC 이름과 일치합니다.
검색된 애플리케이션의 경우
<
namespace>를 제외하고 위의 단계와 동일한 단계를 사용하면 VRG 네임스페이스가 아닌 애플리케이션 워크로드 네임스페이스를 참조합니다.일관성 그룹을 사용한 워크로드의 경우
ReplicationGroupSource를 삭제합니다.
oc delete replicationgroupsource -n <namespace> <name>
$ oc delete replicationgroupsource -n <namespace> <name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 해당 네임스페이스의 모든volSync 작업을 삭제합니다.
oc delete jobs --all -n <namespace>
$ oc delete jobs --all -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 경우 <
namespace>는 워크로드의 네임스페이스(검색되거나 아님)를 나타내며 <name>은 ReplicationGroupSource 리소스의 이름을 나타냅니다.
가상 머신 페이지에서 검색된 앱에서 DR 제거 옵션을 사용할 수 없습니다.
가상 머신 페이지에 나열된 검색된 애플리케이션에는 DR 제거 옵션을 사용할 수 없습니다.
해결방법:
DRPlacementControl에 누락된 라벨을 추가합니다.
{{oc label drplacementcontrol <drpcname> \ odf.console.selector/resourcetype=virtualmachine \ -n openshift-dr-ops}}{{oc label drplacementcontrol <drpcname> \ odf.console.selector/resourcetype=virtualmachine \ -n openshift-dr-ops}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 가상 머신 이름을 값으로 사용하여
PROTECTED_VMSrecipe 매개변수를 추가합니다.{{oc patch drplacementcontrol <drpcname> \ -n openshift-dr-ops \ --type='merge' \ -p '{"spec":{"kubeObjectProtection":{"recipeParameters":{"PROTECTED_VMS":["<vm-name>"]}}}}'}}{{oc patch drplacementcontrol <drpcname> \ -n openshift-dr-ops \ --type='merge' \ -p '{"spec":{"kubeObjectProtection":{"recipeParameters":{"PROTECTED_VMS":["<vm-name>"]}}}}'}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
가상 머신 페이지에서 검색된 앱의 DR 상태가 표시되지 않습니다.
가상 머신 페이지에 나열된 검색된 애플리케이션에 대해서는 DR 상태가 표시되지 않습니다.
해결방법:
DRPlacementControl에 누락된 라벨을 추가합니다.
{{oc label drplacementcontrol <drpcname> \ odf.console.selector/resourcetype=virtualmachine \ -n openshift-dr-ops}}{{oc label drplacementcontrol <drpcname> \ odf.console.selector/resourcetype=virtualmachine \ -n openshift-dr-ops}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 가상 머신 이름을 값으로 사용하여
PROTECTED_VMSrecipe 매개변수를 추가합니다.{{oc patch drplacementcontrol <drpcname> \ -n openshift-dr-ops \ --type='merge' \ -p '{"spec":{"kubeObjectProtection":{"recipeParameters":{"PROTECTED_VMS":["<vm-name>"]}}}}'}}{{oc patch drplacementcontrol <drpcname> \ -n openshift-dr-ops \ --type='merge' \ -p '{"spec":{"kubeObjectProtection":{"recipeParameters":{"PROTECTED_VMS":["<vm-name>"]}}}}'}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
페일오버 후 PVC가 선택 해제되어 보조 VRG의 오래된 항목이 정리되지 않아 후속 재배치가 실패합니다.
워크로드 장애 조치 후에도 PVC를 선택 해제하고 후속 재배치 작업이 preferredCluster로 다시 수행되면 VRG에서 오래된 PVC가 계속 보고될 수 있습니다. 결과적으로 DRPC는 다음과 유사한 메시지와
함께해당 조건을False로 보고할 수 있습니다.클러스터의 VolumeReplicationGroup(/)은 lastGroupSyncTime을 primary로 보고하지 않고 상태가 충족될 때까지 재시도합니다.해결방법:
이 문제를 해결하려면 VRG 상태에서 오래된 PVC(failover 후 선택 해제)를 수동으로 정리하십시오.
- 장애 조치(failover) 후 선택 해제되어 더 이상 보호되지 않는 오래된 PVC를 식별합니다.
<managed-cluster-name>이라는 ManagedCluster에서 VRG 상태를 편집합니다.
oc edit --subresource=status -n <vrg-namespace> <vrg-name>
$ oc edit --subresource=status -n <vrg-namespace> <vrg-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow status.protectedPVCs섹션에서 오래된 PVC 항목을 제거합니다.오래된 항목이 제거되면 DRPC가 복구되고 정상으로 보고됩니다.
검색된 앱에 대해 DR 보호가 제거될 때 보조 PVC는 제거되지 않습니다.
보조 클러스터에서 워크로드에 연결된 CephFS PVC는 일반적으로 VolumeReplicationGroup(VRG)에서 관리합니다. 그러나 Discovered Applications 기능을 사용하여 워크로드가 검색되면 연결된 CephFS PVC가 VRG 소유로 표시되지 않습니다. 결과적으로 워크로드가 비활성화되면 이러한 PVC가 자동으로 정리되지 않고 분리됩니다.
해결방법: 검색된 워크로드에 대해 DR 보호를 비활성화한 후 분리된 CephFS PVC를 정리하려면 다음 명령을 사용하여 수동으로 삭제합니다.
oc delete pvc <pvc-name> -n <pvc-namespace>
$ oc delete pvc <pvc-name> -n <pvc-namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
마이너 업그레이드 후 상태를 재배치하는 DRPC
버전 4.19에서 4.20으로 업그레이드한 후 DRPC(Disaster Recovery Placement Control)는 재배치 상태가 될 수 있습니다. 이 프로세스 중에 다른 이름 지정 규칙을 사용하여 새 VGR(VolumeGroupReplication)이 생성되어 두 개의 VGR이 동일한 PVC를 클레임하려고 합니다. 이 충돌은 DRPC 상태에서 일시적인 불안정성을 유발할 수 있습니다.
해결방법: 이전 VGR(이전 이름 지정 규칙이 있는)을 삭제합니다. 그러면 새 VGR에서 PVC를 성공적으로 클레임하고 DRPC는 잠시 후 정상 상태로 돌아갑니다.
클러스터에 용량을 추가한 후 경고 상태의 Ceph
장치 교체 또는 용량을 추가한 후 Ceph가 HALTH
_WARN상태이며 mon 리포팅 속도가 느려지는 것을 확인할 수 있습니다. 그러나 클러스터의 유용성에는 영향을 미치지 않습니다.
용량 추가 중 OSD Pod 재시작
클러스터에 용량을 추가하여 클러스터 확장을 수행한 후 OSD Pod가 다시 시작됩니다. 그러나 Pod를 다시 시작하는 것 외에도 클러스터에는 영향을 미치지 않습니다.
PVC 선택 해제 후 동기화 중지
그룹 기준과 일치하거나 일치하도록 레이블을 수정하여 PVC(PersistentVolumeClaim)가 그룹에서 추가되거나 제거되면 동기화 작업이 예기치 않게 중지될 수 있습니다. 이는 VolumeReplicationGroup(VRG) 상태에 남아 있는 오래된 보호된 PVC 항목으로 인해 발생합니다.
해결방법:
VRG의 상태 필드를 수동으로 편집하여 오래된 보호된 PVC를 제거합니다.
oc edit vrg <vrg-name> -n <vrg-namespace> --subresource=status
$ oc edit vrg <vrg-name> -n <vrg-namespace> --subresource=statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow
PVs Remain Stuck in Released State After Workload Deletion
최종 동기화 후 모든 임시 PV/PVC가 삭제되지만 일부 PV의 경우
persistentVolumeReclaimPolicy가Retain으로 설정되어 PV가Released상태로 유지됩니다.해결방법:
다음 명령을 사용하여 PVs
persistentVolumeReclaimPolicy를 편집합니다.oc edit pv <pv-name>
$ oc edit pv <pv-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow persistentVolumeReclaimPolicy를Delete로 변경합니다. 정지된 PV가 사라집니다.