4.7 릴리스 노트

IBM Power Systems 일반 가용성 지원

이제 IBM Power Systems를 사용하여 OpenShift Container Storage를 설치 및 관리할 수 있습니다. 자세한 내용은 Deploying OpenShift Container Storage using IBM Power Systems Guide 를 참조하십시오.

IBM Z 및 LinuxONE 일반 가용성 지원

이제 IBM Z 및 LinuxONE을 사용하여 OpenShift Container Storage를 설치 및 관리할 수 있습니다. 자세한 내용은 Deploying OpenShift Container Storage using IBM Z and LinuxONE 에서 참조하십시오.

VMware vSphere 7 일반 가용성 지원

이제 VMware vSphere 7을 사용하여 OpenShift Container Storage를 설치하고 관리할 수 있습니다. 내부 클러스터를 지원하고 외부 클러스터를 소비합니다. 권장 버전은 vSphere 6.7 Update 2 또는 vSphere 7입니다. 자세한 내용은 VMware vSphere 인프라 요구 사항을 참조하십시오.

VMware vSphere 설치 관리자 프로비저닝 인프라 일반 가용성 지원

OpenShift Container Storage는 설치 관리자 프로비저닝 인프라 및 사용자 프로비저닝 인프라에서 VMware vSphere를 사용하여 설치 및 관리할 수 있습니다. 자세한 내용은 Deploying OpenShift Container Storage on VMware vSphere 에서 참조하십시오.

Red Hat Virtualization 일반 가용성 지원

이제 Red Hat Virtualization을 사용하여 OpenShift Container Storage를 설치할 수 있습니다. 자세한 내용은 Red Hat Virtualization을 사용하여 OpenShift Container Storage 배포 및 관리를 참조하십시오.

암호화된 스토리지 데이터

Red Hat OpenShift Container Storage는 스토리지 클러스터의 모든 디스크에 대해 클러스터 전체 암호화(encryption-at-rest)를 지원합니다. 또한 Multicloud Object Gateway 데이터 암호화에도 사용됩니다. 외부 키 관리 시스템(KMS)을 사용하여 Red Hat OpenShift Container Storage 4.7에 암호화 키를 저장할 수 있습니다.

OpenShift Container Storage 클러스터의 유연한 스케일링

유연한 확장을 활성화하면 기본 OSD 3개가 아닌 YAML을 사용하여 한 번에 하나 이상의 OSD를 1개 이상 추가할 수 있습니다. 그러나 클러스터가 균형을 유지하는 방식으로 디스크를 추가해야 합니다.

오브젝트 버킷 클래스에 대한 백업 저장소 구성 업데이트

OpenShift Container Storage 4.7에서는 OpenShift 웹 콘솔을 사용하여 버킷 클래스의 오브젝트 백업 저장소 구성을 업데이트할 수 있습니다.

Multicloud Object Gateway CLI 및 YAML을 사용하여 네임스페이스 버킷 추가

Red Hat OpenShift Container Storage 4.7 설명서에는 Multicloud Object Gateway 명령줄 인터페이스 및 YAML을 사용하여 네임스페이스 버킷을 추가하는 지침이 포함되어 있습니다. 자세한 내용은 Managing hybrid and multicloud resources Guide 를 참조하십시오.

가이드 둘러보기

OpenShift Container Platform 4.7 웹 콘솔의 OpenShift Container Storage 4.7에서 자체 도움말 둘러보기를 사용할 수 있습니다.

OpenShift Container Storage의 성공적인 업그레이드에 대한 더 나은 표시

이전에는 OpenShift Container Storage 업그레이드가 성공적으로 완료되었는지 확인하기 어려웠습니다. 경우에 따라 콘솔에서는 일부 구성 요소가 새 컨테이너 이미지로 업그레이드되지 않은 동안 콘솔에 모든 문제가 제대로 보고되었습니다. 이번 업데이트를 통해 스토리지 클러스터 가 모든 관리 구성 요소에 대해 실행 중인 컨테이너 이미지를 확인하고 보고하여 업그레이드 시나리오 문제 해결에 도움이 됩니다.

OSD Pod 중단 예산 다시 설계

이전 버전에서는 기본적으로 OpenShift Container Storage Pod Disruption Budgets(PDB)에 minUnavailable=0 이 있으며 한 번에 하나의 노드에서 OSD를 재부팅할 수 있었습니다. 이로 인해 OCP 콘솔에서 재시작할 수 없는 노드에 대한 경고가 지속적으로 표시되었습니다. 이번 업데이트를 통해 OSD PDB는 다음과 같은 재 설계가 있습니다.

외부 모드에서 RGW 주소 업데이트

이번 업데이트를 통해 MCG가 외부 모드에서 RGW 백업 저장소로 구성된 경우 Multicloud Object Gateway(MCG) 작업에 영향을 주지 않고 RGW 주소를 변경할 수 있습니다.

RGW의 여유 공간

이전 버전에서는 NooBaa 버킷에 모든 버킷에 대한 1PiB의 스토리지 용량을 표시했으며 RGW에 여유 공간이 표시되지 않았습니다. 이번 개선된 기능을 통해 Red Hat Ceph 클러스터의 스토리지 용량이 상태 필드에 내보내지고 이제 NooBaa Operator가 이 상태 필드를 변경하고 모든 RGW 기반 백업 저장소의 사용 가능한 용량을 업데이트합니다.

서비스 모니터 포트 구성이 외부 모드의 기본 ceph-mgr Prometheus 포트와 다를 수 있도록 허용

이번 개선된 기능을 통해 기본이 아닌 포트(9283)에서 수신 대기하는 ceph-mgr Prometheus 모듈을 사용하여 외부 Red Hat Ceph 클러스터가 구성된 경우 OpenShift Container Storage는 이제 이러한 메트릭을 연결하고 사용할 수 있습니다. 즉, OpenShift Container Storage는 이제 모든 모니터링 포트를 허용합니다.

OCS-operator는 외부 모드의 서비스 모니터링을 위해 기본이 아닌 포트를 허용합니다.

이전 버전에서는 ocs-operator 에 기본 포트 9283 이외의 모니터링 Prometheus 서비스 포트에서 전달할 프로비저닝이 없었습니다. 이로 인해 모니터링 서비스에 포트를 사용할 수 없게 되었습니다. 이번 업데이트를 통해 외부 클러스터 JSON 입력 및 모니터링 서비스의 기본이 아닌 모니터링 포트를 수락 및 전파하도록 ocs-operator 가 예상대로 작동합니다.

기존 시크릿을 사용하여 새 백업 저장소 생성

이번 개선된 기능을 통해 기존 보안을 사용하여 Multicloud Object Gateway CLI를 통해 새로운 백업 저장소를 생성할 수 있습니다.

기존 OSD 배포 업데이트를 통한 새 OSD 배포 생성 우선 순위

이전 버전에서는 영구 볼륨 클레임의 OSD의 경우 Rook에서 새 OSD를 생성하기 전에 기존 OSD를 업데이트하는 것을 선호했기 때문에 OSD 조정이 종료될 때까지 새 OSD가 클러스터에 추가되지 않았습니다. 이번 개선된 기능을 통해 이제 클러스터에서 기존 OSD를 업데이트하여 스토리지를 프로비저닝하는 즉시 새 용량을 사용할 수 있도록 OSD를 확장하도록 선호하고 이로 인해 클러스터에서 OSD 수를 확장하면서 조정 시간을 15에서 5-10분으로 줄일 수 있습니다.

RGW의 공개 경로

이번 업데이트를 통해 OpenShift Container Storage Operator에서 Red Hat Ceph Storage의 RADOS Object Gateway(RGW) 서비스에 대한 경로를 생성합니다.

IBM 클라우드 설정에서 인증 정보 없이 ROKS에 배포된 OpenShift Container Storage

이번 업데이트를 통해 OpenShift Container Storage가 ROKS에 배포될 때 IBM 클라우드 설정에 쉽게 설치할 수 있으며 기본 백업 저장소로 ROKS를 사용하기 위한 인증 정보가 제공되지 않는 경우 PV 풀 기본 백업 저장소가 생성됩니다.

OSD 재시작을 위한 Prometheus 경고

이번 개선된 기능에는 OpenShift Container Storage OSD가 5분 후에 5번 이상 다시 시작될 때 알리는 Prometheus 경고가 추가되었습니다. 경고 메시지는 다음과 같습니다.

네임스페이스 버킷에 대한 시스템 경고

Red Hat OpenShift Container Storage 4.7이 릴리스되면서 현재 시스템 상태를 보다 잘 이해할 수 있도록 네임스페이스 버킷 및 리소스에 대한 시스템 경고가 추가되었습니다.

noobaa-endpoint Pod 로그에 출력되는 로그 메시지

이전 버전에서는 debug 옵션이 설정되지 않은 경우에도 noobaa-endpoint Pod 로그에 로그 메시지가 출력되었습니다. 이번 릴리스에서는 debug 옵션이 설정된 경우에만 로그 메시지가 noobaa-endpoint Pod 로그에 출력됩니다.

MON이 다운된 경우에도 MGR Pod가 재시작됩니다.

이전 버전에서는 노드가 MGR Pod를 재시작하면 Pod 초기 설정 상태가 발생하여 새 PV(영구 볼륨)를 생성할 수 없었습니다. 이번 업데이트를 통해 MON이 다운된 경우에도 MGR 포드가 다시 시작됩니다.

OpenShift Container Platform에서 hugepages가 활성화된 경우 Multicloud Object Gateway를 사용할 수 있습니다.

이전 버전에서는 hugepages가 활성화된 경우 Postgres가 kubernetes에서 실행되지 않아 MCG(Multicloud Object Gateway) db pod가 충돌했습니다. 현재 업데이트를 통해 MCG Postgres Pod의 hugepages가 비활성화되어 MCG db Pod가 충돌하지 않습니다.

PodDisruptionBudget 경고가 더 이상 지속적으로 표시되지 않습니다.

이전에는 OpenShift Container Platform 경고인 PodDisruptionBudget 경고가 오브젝트 스토리지 장치(OSD)에 대해 지속적으로 표시되었습니다. 기본 문제가 수정되었으며 더 이상 경고가 표시되지 않습니다.

must-gather 로그 수집 실패

이전 버전에서는 복사 Pod에서 데이터를 정기적으로 다시 사용하지 않아 기본 10분 후에 must-gather 명령이 실패하게 되었습니다. 이번 업데이트를 통해 copy Pod는 must-gather 명령으로 생성된 정기적으로 데이터를 수집하려고 하며 이제 must-gather 명령이 완료될 때까지 실행됩니다.

volumesnapshotclass가 없는 경우 볼륨 스냅샷에서 PVC를 생성할 수 없습니다.

volumesnapshotclass 가 없는 경우 볼륨 스냅샷에서 PVC를 생성할 수 없습니다. 이 문제는 볼륨 스냅샷의 상태가 volumesnapshotclass 삭제 시 준비되지 않은 상태로 변경되었기 때문입니다. 이 문제는 OCP 4.7.0 이상에서 해결되었습니다.

프로세스가 충돌하면 코어 덤프가 전파되지 않음

이전에는 프로세스가 충돌한 경우 코어 덤프가 전파되지 않았습니다. 이번 릴리스에서는 기본 ceph 데몬 옆에 있는 log-collector - 사이드카가 도입되었습니다. 이 경우 shareProcessNamespace 플래그가 활성화되고 이 플래그 신호를 컨테이너 간에 가로채어 coredumps를 생성할 수 있습니다.

Mulitple OSD 제거 작업이 더 이상 실패하지 않습니다.

이전 버전에서는 여러 OSD 제거를 위해 작업을 트리거할 때 템플릿에 작업 이름의 OSD ID가 쉼표로 포함되어 있었습니다. 이로 인해 작업 템플릿이 실패했습니다. 이번 업데이트를 통해 유효한 형식을 유지하기 위해 OSD ID가 작업 이름에서 제거되었습니다. 작업 이름이 ocs-osd-removal-${FAILED_OSD_IDS} 에서 ocs-osd-removal-job 으로 변경되었습니다.

mon failover timeout 증가

이번 업데이트에서는 IBM Cloud에서 mon failover timeout이 15분으로 증가했습니다. 이전에는 몬드가 다가오는 동안 장애 조치(failover)가 시작되었습니다.

이제 rook에서 이전 OpenShift Container Storage 설치에서 불명확 디스크 감지에 대한 메시지와 함께 OSD 배포를 거부합니다.

이전 버전에서는 OpenShift Container Storage의 이전 설치에서 정리되지 않은 디스크를 재사용하면 Rook에서 강제로 작동하지 않았습니다. 이번 업데이트를 통해 Rook에서 디스크가 다른 클러스터에 속하는 것을 감지하고 오류 메시지와 함께 해당 디스크의 OSD 배포를 거부할 수 있습니다(BZ#1922954).

Mon failover로 인해 더 이상 Ceph에 액세스할 수 없습니다.

이전 버전에서는 다른 몬이 넘어진 동안 원이 내려지면 몬이 쿼럼을 잃을 수 있었습니다. mons가 쿼럼이 손실되면 Ceph에 액세스할 수 없습니다. 이번 업데이트에서는 mon이 장애 조치되어 Ceph에 액세스할 수 없게 되는 동안 자발적으로 mon drains를 방지할 수 있습니다.

GRPC 메트릭에 대해 cpehcsi 노드 플러그인 Pod 사전 배치 포트

이전 버전에서는 cephcsi Pod에서 디버깅 목적으로 GRPC 메트릭을 표시했기 때문에 cephcsi 노드 플러그인 Pod에서 CephFS의 경우 RBD 및 9091의 포트 9090을 사용했습니다. 결과적으로 포트를 사용할 수 없어 cephsi Pod가 시작되지 않았습니다. 이번 릴리스에서는 디버깅에만 필요한 경우에만 GRPC 메트릭이 비활성화되어 있으며 이제 cephcsi 는 노드 플러그인 Pod가 실행 중인 노드에서 포트 9091 및 9090을 사용하지 않습니다.

rook-ceph-mds 는 모니터 서버에 Pod IP를 등록하지 않았습니다.

이전 버전에서는 rook-ceph-mds 가 모니터 서버에 Pod IP를 등록하지 않았기 때문에 시간 초과된 파일 시스템에 있는 모든 마운트를 프로비저닝할 수 없었습니다. 따라서 CephFS 볼륨 프로비저닝에 오류가 발생할 수 없었습니다. 이번 릴리스에서는 호스트 네트워크가 활성화되지 않은 경우 MDS Pod에 --public-addr=podIP 인수를 추가합니다. 따라서 이제 CephFS 볼륨 프로비저닝이 실패하지 않습니다.

의 오류는 규칙 평가 실패로 인해 수집되어야 합니다.

이전 버전에서는 기록 규칙 레코드: cluster:ceph_disk_latency:join_ceph_node_disk_irate1m 은 Prometheus에서 다대다 일치가 허용되지 않기 때문에 평가되지 않았습니다. 그 결과 이 실패한 규칙 평가로 인해 를 수집하고 배포에 오류가 발생했습니다. 이번 릴리스에서는 다대다 일치 시나리오를 제거하도록 레코딩 규칙 쿼리가 업데이트되어 이제 Prometheus 규칙 평가가 실패하지 않아야 하며 배포에 표시되는 오류가 없어야 합니다.

스토리지 클래스를 통한 영구 볼륨 암호화

외부 키 관리 시스템(KMS)을 사용하여 스토리지 클래스 암호화로 영구 볼륨(블록만 해당)을 암호화하여 장치 암호화 키를 저장할 수 있습니다. 영구 볼륨 암호화는 RADOS Block Device(RBD) 영구 볼륨에만 사용할 수 있습니다. OpenShift Container Storage 4.7 이상에서는 스토리지 클래스 암호화가 지원됩니다. 자세한 내용은 영구 볼륨 암호화로 스토리지 클래스를 생성하는 방법을 참조하십시오.

중재자를 사용한 재해 복구

Red Hat OpenShift Container Storage는 이제 메쉬 재해 복구 (stretched cluster - Arbiter) 기능을 제공합니다. 이 기능을 사용하면 스토리지 클러스터 생성 중에 세 번째 영역이 있는 두 영역에서 단일 클러스터를 확장할 수 있습니다. 자세한 내용은 배포 계획 가이드의 재해 복구를 참조하십시오.

오브젝트 버킷에 대한 캐싱 정책

Red Hat OpenShift Container Storage의 Multicloud Object Gateway에서 캐시 버킷을 생성할 수 있습니다. 캐시 버킷은 허브 대상과 캐시 대상이 있는 네임스페이스 버킷입니다. 자세한 내용은 개체 버킷에 대한 정책 캐싱 을 참조하십시오.

Red Hat OpenStack Platform 기술 프리뷰 지원

이제 Red Hat OpenStack Platform을 사용하여 OpenShift Container Storage를 설치 및 관리할 수 있습니다. 자세한 내용은 Red Hat OpenStack Platform을 사용하여 OpenShift Container Storage 배포 및 관리 가이드 를 참조하십시오.

최소 배포 기술 프리뷰 지원

표준 배포 리소스 요구 사항이 충족되지 않은 경우 OpenShift Container Storage를 최소 구성으로 배포할 수 있습니다. 자세한 내용은 계획 가이드의 최소 배포 리소스 요구 사항을 참조하십시오.

컴팩트한 배포 기술 프리뷰 지원

이제 OpenShift Container Storage를 3개의 강력한 마스터 노드에서 실행되는 3-노드 OpenShift 컴팩트 베어 메탈 클러스터에 설치할 수 있습니다. 작업자 또는 스토리지 노드가 없습니다.

추가 장치를 사용하여 스토리지 용량 확장

이제 관리자는 배포 중에 정의된 스토리지 클래스 이외의 스토리지 클래스를 사용하여 스토리지 용량을 확장할 수 있습니다. 먼저 기존 스토리지 공급자를 기반으로 새 스토리지 클래스를 정의하고 OpenShift Container Storage 용량을 확장해야 하는 경우 해당 스토리지 클래스를 선택합니다. 자세한 내용은 스토리지 스케일링 을 참조하십시오.

새 읽기 전용 액세스 모드로 스냅샷 복제 또는 복원

Red Hat OpenShift Container Storage 4.7을 사용하면 읽기 전용(RXO) 액세스 모드로 복제를 생성하거나 볼륨 스냅샷을 복원할 수 있습니다. 자세한 내용은 새 ROX 액세스 모드로 복제본 생성 또는 스냅샷 복원을 참조하십시오.

다중 클러스터 재해 복구

Red Hat OpenShift Container Storage는 두 개의 Openshift Container Platform 클러스터를 제공하는 두 OpenShift Container Storage 클러스터에서 다중 클러스터 비동기 스토리지 복제를 제공합니다. 상태 비저장 상대를 포함한 모든 상태 저장 애플리케이션에는 피어 클러스터에 동일하게 배포하기 전에 약간의 준비가 필요합니다.

미디어 유형에 따른 다양한 스토리지 클래스의 가용성

이제 사용자는 클러스터에서 혼합 미디어를 사용하여 비용을 절감하고 중요한 워크로드에 대해 잘 수행된 장치를 제공하고 다른 워크로드에서 느린 장치를 제공할 수 있습니다.

유연한 장치

이제 사용자는 사용할 수 있는 장치를 결정할 수 있는 유연성을 확보할 수 있습니다. Red Hat은 베어 메탈 설치의 구성 변경 없이 모든 드라이브 크기를 최대 16TB의 개발 프리뷰로 지원합니다.

OSD에 대한 쓰기 로깅 PVC 지원

OpenShift Container Storage는 이제 Bluestore의 busys db 데이터베이스와 다른 장치에 키 쓰기 로그를 분리하는 동안 OSD 배포를 지원합니다. OSD는 SSD에 비해 최소한의 IOPS로 인해 HDD에서 성능이 저하됩니다. 이를 통해 사용자는 HDD에서 지정된 OSD에 대한 메타데이터에 SSD를 사용하여 성능을 향상시킬 수 있습니다.

RHCS 클러스터에서 활성 mgr 변경 사항이 있으면 RGW 메트릭을 더 이상 사용할 수 없습니다.

활성 MGR이 외부 클러스터 모드로 전환되면 OpenShift Container Platform(OCP)은 MGR이 다시 실행된 경우에도 RHCS(Red Hat Ceph Storage) 클러스터에서 추가 지표 수집을 중지합니다. 즉, 현재 활성 MGR에 대한 연결이 손실되면 RADOS Object Gateway(RGW) 지표가 더 이상 수집되지 않습니다.

OpenShift Container Storage 클러스터 설치 중 Vault의 OSD 키는 삭제되지 않습니다.

현재 OSD의 키 암호화 키는 Vault Key/V(Key/V) Secret 엔진 API를 삭제할 때 Vault에서 소프트 삭제되며 KMS와 클러스터 전체 암호화에 버전 2가 사용됩니다. 즉, 키 메타데이터가 계속 표시되고 키의 모든 버전을 검색할 수 있습니다.

MDS 보고서 초과 캐시

업그레이드 시 rook이 이전에 mds_cache_memory_limit 를 적용하지 않았습니다. 즉, 해당 옵션이 적용되지 않은 OpenShift Container Storage 4.2 클러스터는 올바른 값으로 업데이트되지 않았습니다. 이는 일반적으로 Pod 메모리 제한 크기의 절반입니다. 따라서 standby-replay의 MDSs는 초과화된 캐시를 보고할 수 있습니다.

flexibleScaling 및 arbiter가 모두 활성화되면 스토리지 클러스터 단계가 준비 됨

중재자 및 유연한 스케일링이 활성화되면 스토리지 클러스터 CR에 대한 잘못된 사양이 있습니다. 즉, 오류 arbiter 및 flexibleScaling이 둘 다 활성화된 상태로 로그 또는 메시지가 있는 경우에도 사용자가 스토리지 클러스터를 READY 상태로 볼 수 없습니다. 이는 기능에 영향을 미치지 않습니다.

중재자 노드는 OpenShift Container Storage 노드 레이블로 라벨을 지정할 수 없습니다.

arbiter 노드는 OpenShift Container Storage 노드 레이블, cluster.ocs.openshift.io/openshift-storage 로 레이블이 지정된 경우 유효한 비호환 노드로 간주됩니다. 즉, 비arbiter 리소스에 대한 배치가 결정되지 않습니다. 이 문제를 해결하려면 중재자 리소스만 중재자 노드에 배치되도록 OpenShift Container Storage 노드 레이블로 중재자 노드에 라벨을 지정하지 마십시오.

noobaa-db-pg-0문제

NooBaa-db-pg-0 포드는 호스팅 노드가 중단된 경우 다른 노드로 마이그레이션되지 않습니다. noobaa-db-pg-0 Pod의 마이그레이션으로 노드가 차단되면 NooBaa가 작동하지 않습니다.

상위 PVC보다 큰 크기의 스냅샷/복제 작업을 복원하면 무한한 루프가 발생합니다.

Ceph CSI는 상위 PVC보다 큰 스냅샷 복원 또는 복제본 생성을 지원하지 않습니다. 따라서 더 큰 크기를 가진 스냅샷/복제 작업을 복원하면 무한한 루프가 발생합니다. 이 문제를 해결하려면 보류 중인 PVC를 삭제합니다. 더 큰 PVC를 얻으려면 사용 중인 작업에 따라 다음 중 하나를 완료합니다.

디스크 교체 후 Ceph 상태는 HEALTH_WARN 입니다.

디스크 교체 후 모든 OSD Pod가 가동되고 실행 중인 경우에도 경고 1 데몬이 최근에 충돌 한 것으로 표시됩니다. 이 경고는 Ceph 상태가 변경됩니다. Ceph 상태는 HEALTH_WARN 대신 HEALTH_OK 여야 합니다. 이 문제를 해결하기 위해 ceph-tools 포드에 대한 rsh 를 확인하고 경고를 음소거하면 Ceph 상태가 HEALTH_OK 로 돌아갑니다.

암호화된 OpenShift Container Storage 클러스터의 사용자 인터페이스를 통해 장치 교체 작업을 수행할 수 없습니다.

암호화된 OpenShift Container Storage 클러스터에서 검색 결과 CR은 Ceph OSD(Object Storage Daemon)에서 Ceph 경고에 보고된 장치와 다르게 검색합니다. 경고를 클릭하면 사용자에게 Disk not found 메시지가 표시됩니다. 불일치로 인해 콘솔 UI에서 OpenShift Container Storage 사용자에 대한 디스크 교체 옵션을 활성화할 수 없습니다. 이 문제를 해결하려면 장치 교체 가이드의 실패한 장치 교체 에 대한 CLI 절차를 사용하십시오.

새로 복원된 PVC를 마운트할 수 없음

일부 OCP 노드가 8.2 미만의 Red Hat Enterprise Linux 버전에서 실행되고 있고 복원된 스냅샷이 삭제된 경우 새로 복원된 PVC를 마운트할 수 없습니다. 이 문제를 방지하려면 복원된 PVC가 삭제될 때까지 PVC가 복원되는 스냅샷을 삭제하지 마십시오.

교체를 시작하기 전에 디스크의 상태가 교체 준비 됨

두 디스크의 이름이 모두 동일한 경우 사용자 인터페이스에서 다른 또는 동일한 노드의 새 디스크 오류와 이전에 실패한 디스크를 구별할 수 없습니다. 동일한 이름 문제로 인해 사용자 인터페이스에서 새로 실패한 디스크가 이미 교체되었다고 간주하면 디스크 교체가 허용되지 않습니다. 이 문제를 해결하려면 다음 단계를 따르십시오.