6장. 버그 수정


이 섹션에서는 Red Hat OpenShift Data Foundation 4.14에 도입된 주요 버그 수정 사항에 대해 설명합니다.

6.1. 재해 복구

  • 차단 목록에 더 이상 오류 상태가 되는 Pod가 발생하지 않음

    이전 버전에서는 네트워크 문제 또는 과도한 과부하 또는 불균형이 높은 클러스터로 인해 차단 대기 시간이 급증했습니다. 이로 인해 Pod는 Error : relabel failed /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7-4ae7-4ae766: lsetxattr /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80ae7610bb613/mount/#ib_16384_0.dblwr: 읽기 전용 파일 시스템.

    이번 수정으로 blocklisting으로 인해 더 이상 오류 상태가 되는 Pod가 발생하지 않습니다.

    (BZ#2094320)

  • Ceph에서 Globalnet에서 할당한 글로벌 IP 인식

    이전에는 Ceph가 Globalnet에서 할당한 글로벌 IP를 인식하지 못했기 때문에 Globalnet을 사용하여 서비스 CIDR이 겹치는 클러스터 간에 재해 복구 솔루션을 구성할 수 없었습니다. 이 문제는 해결되었으며 서비스 CIDR이 겹치는 경우 재해 복구 솔루션이 작동합니다.

    (BZ#2104971)

  • PeerReady 상태는 워크로드가 장애 조치되거나 실패한 위치에서 클러스터가 정리될 때까지 워크로드가 장애 조치되거나 피어 클러스터로 재배치될 때 더 이상 true 로 설정되지 않습니다.

    이전 버전에서는 재해 복구(DR) 작업이 시작된 후 워크로드가 장애 조치되거나 피어 클러스터로 재배치된 기간 동안 PeerReady 조건이 true 로 설정되었습니다. 이 경우 오류가 발생하거나 재배치된 클러스터가 향후 작업을 위해 정리될 때까지 false 로 설정되었습니다. 향후 작업에 대해 DRPlacementControl 상태 조건을 보는 사용자는 이 중간 PeerReady 상태를 피어가 작업을 준비하고 수행할 준비가 되었음을 인식할 수 있습니다. 이로 인해 작업이 보류 중이거나 실패할 수 있으며 복구하기 위해 사용자 개입이 필요할 수 있습니다.

    이번 수정을 통해 클러스터가 정리될 때까지 실패한 워크로드 또는 재배치된 워크로드에서 PeerReady 상태가 더 이상 true 로 설정되지 않으므로 사용자에게 더 이상 혼동이 발생하지 않습니다.

    (BZ#2138855)

  • 재해 후 ACM 허브를 복구할 때 애플리케이션이 더 이상 정리 상태로 유지되지 않음

    이전에는 ACM 허브가 재해 발생 중에 손실되고 백업을 사용하여 복구되면 VRG ManifestWork 및 DRPC 상태가 복원되지 않았습니다. 이로 인해 애플리케이션이 정리 상태가 되었습니다.

    이번 수정으로 Ramen은 VRG ManifestWork가 ACM 백업의 일부임을 확인하고 허브 복구 후 비어 있는 경우 DRPC 상태를 다시 빌드하고 애플리케이션이 장애 조치 클러스터로 성공적으로 마이그레이션됩니다.

    (BZ#2162469)

  • STS 기반 애플리케이션을 이제 예상대로 재배치할 수 있습니다.

    이전에는 기본 버그로 인해 STS 기반 애플리케이션을 재배치하지 못했습니다. 이 버그가 수정되었으며 STS 기반 애플리케이션을 재배치하는 것이 이제 예상대로 작동합니다.

    (BZ#2224325)

  • Ramen는 허브 복원 후 예상대로 조정

    이전에는 활성/수동 Hub Metro-DR 설정으로 작업하는 동안 허용된 속도 제한 매개변수를 초과한 후 Ramen 조정기에서 실행을 중지하는 드문 경우가 있을 수 있었습니다. 조정은 각 워크로드에 고유하므로 해당 워크로드에만 영향을 미쳤습니다. 이러한 경우 해당 워크로드와 관련된 모든 재해 복구 오케스트레이션 활동이 Ramen pod가 다시 시작될 때까지 중지되었습니다.

    이 문제가 해결되었으며 Ramen은 허브 복원 후 예상대로 조정됩니다.

    (BZ#2175201)

  • 허브 복구 중에 관리되는 리소스가 더 이상 삭제되지 않음

    이전 버전에서는 허브 복구 중에 OpenShift Data Foundation에서 서브스크립션 기반 워크로드와 관련된 특정 관리 리소스가 의도하지 않게 삭제되었을 수 있는 Red Hat Advanced Cluster Management 버전 2.7.4 이상에서 알려진 문제가 발생했습니다.

    이 문제는 해결되었으며 허브 복구 중에 관리되는 리소스가 삭제되지 않습니다.

    (BZ#2211643)

6.1.1. DR 업그레이드

이 섹션에서는 재해 복구 환경에서 Red Hat OpenShift Data Foundation을 버전 4.13에서 4.14로 업그레이드하는 것과 관련된 버그 수정 사항에 대해 설명합니다.

  • 업그레이드하기 전에 존재했던 워크로드에 대해 장애 조치 또는 재배치가 더 이상 차단되지 않음

    이전에는 업그레이드 전에 존재했던 워크로드에 대해 장애 조치 또는 재배치가 차단되었습니다. 이는 OpenShift Data Foundation Disaster 복구 솔루션이 PV(영구 볼륨) 데이터 외에도 PVC(영구 볼륨 클레임) 데이터를 보호하고 워크로드에 PVC 데이터가 백업되지 않았기 때문입니다.

    이번 수정으로 업그레이드 전에 존재하는 워크로드에 대해 장애 조치 또는 재배치가 더 이상 차단되지 않습니다.

    (BZ#2229568)

  • DRPC에 더 이상 잘못된 값이 캐시되지 않음

    이전 버전에서는 OpenShift Data Foundation이 업그레이드되면 재해 복구 배치 제어(DRPC)가 status.preferredDecision.ClusterNamespace 에 캐시된 잘못된 값이 있을 수 있었습니다. 이 문제는 해결되었으며 잘못된 값은 더 이상 캐시되지 않습니다.

    (BZ#2229567)

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.