지원콘솔개발자평가판 시작연락처

6.2. regional-DR 문제 해결

6.2.1. 일부 이미지에서 RBD 미러링 스케줄링이 중지됨

문제

일부 이미지에는 RBD 미러링 스케줄링이 중지되는 몇 가지 일반적인 원인이 있습니다.

미러링을 위해 애플리케이션을 표시한 후 어떤 이유로 복제되지 않은 경우 toolbox Pod를 사용하고 다음 명령을 실행하여 중지된 이미지 스케줄링을 확인합니다. 

$ rbd snap ls <poolname/imagename> –all
해결
  • 기본 클러스터에서 관리자 데몬을 다시 시작
  • 기본 클러스터의 영향을 받는 이미지에서 미러링을 비활성화하고 즉시 다시 활성화합니다.

BZ 참조: [2067095 및 2121514]

6.2.2. RBD-mirror 데몬 상태가 경고 상태에 있습니다.

문제

미러 서비스 :get_mirror_service_status 가 Ceph 모니터를 호출하여 rbd-mirror 의 서비스 상태를 가져옵니다.

네트워크 연결을 끊습니다. rbd-mirror 데몬 상태는 경고 상태에 있으며 두 관리 클러스터 간 연결이 정상입니다.

해결

도구 상자에서 다음 명령을 실행하고 leader:false를 찾습니다. 

rbd mirror pool status --verbose ocs-storagecluster-cephblockpool | grep 'leader:'

출력에 다음이 표시되면 다음을 수행합니다.

leader: false

데몬 시작 문제가 발생했으며 가장 가능성이 높은 근본 원인은 보조 클러스터에 안정적으로 연결하는 문제로 인한 것일 수 있습니다.

해결방법: pod를 삭제하고 다른 노드에서 다시 예약되었는지 확인하여 rbd-mirror Pod를 다른 노드로 이동합니다.

leader: true 또는 no output

Red Hat 지원에 문의하십시오.

BZ 참조: [2118627]

6.2.3. 장애 조치 후 statefulset 애플리케이션이 중지됨

문제

기본 클러스터로 재배치하는 동안 DRPlacementControl은 PROGRESSION을 "MovingToSecondary"로 보고했습니다.

이전에는 Kubernetes v1.23 이전에는 Kubernetes 컨트롤 플레인에서 StatefulSets용으로 생성된 PVC를 정리하지 않았습니다. 이 활동은 클러스터 관리자 또는 StatefulSets를 관리하는 소프트웨어 운영자에게 맡았습니다. 이로 인해 Pod가 삭제될 때 StatefulSets의 PVC가 변경되지 않았습니다. 이렇게 하면 Ramen에서 애플리케이션을 기본 클러스터에 재배치하지 않습니다.

해결

  1. 워크로드가 StatefulSets를 사용하고 재배치가 PROGRESSION으로 "MovingToSecondary"로 고정되면 다음을 실행합니다. 

    $ oc get pvc -n <namespace>

  2. StatefulSet에 속하는 해당 네임스페이스의 바인딩된 각 PVC에 대해 다음을 실행합니다. 

    $ oc delete pvc <pvcname> -n namespace

    모든 PVC가 삭제되면 VRG( Volume Replication Group)가 보조로 전환된 후 삭제됩니다.

  3. 다음 명령을 실행하십시오. 

    $ oc get drpc -n <namespace> -o wide

    몇 초에서 몇 분 후에 PROGRESSION은 "완전"을 보고하고 재배치가 완료됩니다.

결과
워크로드를 기본 클러스터로 재배치

BZ 참조: [2118270]

6.2.4. 장애 조치(failover) 후 애플리케이션이 실행되지 않음

문제
애플리케이션을 통해 오류가 발생한 후 워크로드 Pod가 volume <PV name> : rpc 오류: code = Internal desc = fail to check rbd 이미지 상태를 확인하지 못했습니다. (이미지 <image description>은 기본이 아님) 오류가 있는 실행 상태에 도달하지 않습니다.
참고

워크로드가 장애 조치되는 클러스터에서 다음 단계를 실행합니다.

해결

  1. 위 오류에서 애플리케이션 Pod를 복구할 수 있을 때까지 RBD 미러 데몬 배포를 0 으로 축소합니다. 

    $ oc scale deployment rook-ceph-rbd-mirror-a -n openshift-storage --replicas=0

  2. 복구 후 RBD 미러 데몬 배포를 다시 1 로 확장합니다. 

    $ oc scale deployment rook-ceph-rbd-mirror-a -n openshift-storage --replicas=1

BZ 참조: [2134936]

6.2.5. volsync-rsync-src Pod는 오류 상태에 있습니다.

문제

volsync-rsync-src 포드는 volsync-rsync-dst 에 연결할 수 없기 때문에 오류 상태에 있습니다. Rest icSync 소스 Pod 로그에는 로그 조각과 유사한 연장된 기간 동안 지속적인 오류 메시지가 표시될 수 있습니다.

다음 명령을 실행하여 로그를 확인합니다. 

$ oc logs volsync-rsync-src-<app pvc name>-<suffix>

출력 예 

VolSync rsync container version: ACM-0.6.0-ce9a280
Syncing data to volsync-rsync-dst-busybox-pvc-9.busybox-workloads-1.svc.clusterset.local:22
Syncronization failed. Retrying in 2 seconds. Retry 1/5.
rsync: connection unexpectedly closed (7 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.3]
해결

최대 전송 단위(MTU) 크기를 재구성하여 다음 단계를 사용하여 이 문제를 해결할 수 있습니다.

  1. 서브마인러 게이트웨이 레이블이 있는 노드에 주석을 답니다. 

    $ oc annotate node -l submariner.io/gateway submariner.io/tcp-clamp-mss=1340 --overwrite

    출력 예 

    node/compute-0 annotated
node/compute-2 annotated

  2. submariner 경로 에이전트 pod를 삭제합니다. 

    $ oc delete pods -n submariner-operator -l app=submariner-routeagent

    출력 예 

    pod "submariner-routeagent-4r66z" deleted
pod "submariner-routeagent-4tn6d" deleted
pod "submariner-routeagent-9r42l" deleted
pod "submariner-routeagent-bg5wq" deleted
pod "submariner-routeagent-gzqdj" deleted
pod "submariner-routeagent-j77jq" deleted

  3. vol-sync-src Pod에서 오류를 확인합니다. 

    $ oc logs volsync-rsync-src-dd-io-pvc-3-nwn8h

    출력 예 

    VolSync rsync container version: ACM-0.6.0-ce9a280
Syncing data to volsync-rsync-dst-dd-io-pvc-3.busybox-workloads-8.svc.clusterset.local:22 …
.d..tp..... ./
<f+++++++++ 07-12-2022_13-03-04-dd-io-3-5d6b4b84df-v9bhc

BZ 참조: [2136864]

6.2.6. 대상 호스트 이름을 확인할 수 없기 때문에 volsync-rsync-src Pod가 오류 상태에 있습니다.

문제

ResticSync 소스 Pod는 MellanoxSync 대상 Pod의 호스트 이름을 확인할 수 없습니다. ECDHESync 포드의 로그는 다음 로그 조각과 유사한 오랜 기간 동안 오류 메시지를 일관되게 표시합니다. 

$ oc logs -n busybox-workloads-3-2 volsync-rsync-src-dd-io-pvc-1-p25rz

출력 예 

VolSync rsync container version: ACM-0.6.0-ce9a280
Syncing data to volsync-rsync-dst-dd-io-pvc-1.busybox-workloads-3-2.svc.clusterset.local:22 ...
ssh: Could not resolve hostname volsync-rsync-dst-dd-io-pvc-1.busybox-workloads-3-2.svc.clusterset.local: Name or service not known
해결

두 노드 모두에서 submariner-lighthouse-agent 를 다시 시작합니다. 

$ oc delete pod -l app=submariner-lighthouse-agent -n submariner-operator

6.2.7. RHACM 2.8을 사용하여 서브스크립션 워크로드에 DRPolicy를 적용할 수 없음

문제
RHACM(Red Hat Advanced Cluster Management) 2.8 콘솔은 PlacementRule 유형을 더 이상 사용하지 않고 서브스크립션 애플리케이션의 배치 유형으로 이동했습니다. 따라서 사용자가 RHACM 2.8 콘솔을 사용하여 서브스크립션 애플리케이션을 생성하면 배치만 사용하여 애플리케이션이 생성됩니다. OpenShift Data Foundation 4.12 재해 복구 사용자 인터페이스와 Ramen Operator는 서브스크립션 애플리케이션에 대한 배치를 지원하지 않으므로 재해 복구 사용자 인터페이스는 애플리케이션을 감지하고 정책 할당 세부 정보를 표시할 수 없습니다.
해결

RHACM 2.8 콘솔은 CLI(명령줄 인터페이스)를 사용하여 생성된 PlacementRule 을 탐지할 수 있으므로 PlacementRule 을 사용하여 RHACM 2.8에서 서브스크립션 애플리케이션을 생성하기 위한 다음 단계를 수행합니다.

  1. 애플리케이션 네임스페이스를 사용하여 새 프로젝트를 생성합니다. (예: busybox-application)
  2. 애플리케이션을 배포할 관리형 클러스터의 레이블을 찾습니다. (예: drcluster1-jul-6)

  3. 이전 단계에서 생성된 관리형 클러스터 라벨을 사용하여 application-namespace 에 PlacementRule CR을 생성합니다. 

    apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  labels:
    app: busybox-application
  name: busybox-application-placementrule-1
  namespace: busybox-application
spec:
  clusterSelector:
    matchLabels:
      name: drcluster1-jul-6
  4. 서브스크립션 애플리케이션 페이지에서 RHACM 콘솔을 사용하여 애플리케이션을 생성하는 동안 이 새 PlacementRule 을 선택합니다.
  5. YAML 편집기에서 PlacementRule 을 삭제하여 선택한 항목을 다시 사용할 수 있습니다.

BZ 참조: [2216190]

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.