PowerProtect Data Manager 19.8에서 ConfigMap을 사용하여 스냅샷 영구 볼륨 클레임에 스토리지 클래스를 매핑하는 방법
Summary: 이 문서에서는 백업 중에 백업 스냅샷 영구 볼륨 클레임을 활성화하여 사용자 정의 스토리지 클래스에 바인딩하는 방법에 대해 설명합니다.
Instructions
Dell EMC PowerProtect Data Manager 19.8 및 ConfigMap을 사용하여 백업 중에 사용자 정의 스토리지 클래스에 바인딩되는 백업 스냅샷 영구 볼륨 클레임을 활성화하려면 다음 지침을 따르십시오.
이 문서는 다음 시나리오를 다룹니다.
- Kubernetes 클러스터에 2개의 스토리지 클래스가 정의되어 있습니다. 예:
debjeet@irv-ppdm-sdr-140:~$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
csi-hostpath-sc (default) hostpath.csi.k8s.io Delete Immediate true 161d
debjeet-sc hostpath.csi.k8s.io Delete Immediate true 12d
- 예를 들어 애플리케이션 네임스페이스는 첫 번째 스토리지 클래스를 사용합니다.
NAME READY STATUS RESTARTS AGE
pod/wordpress-mysql-5b697dbbfc-gfv9k 1/1 Running 0 16d
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/mysql-pv-claim Bound pvc-d6df4270-dc9e-48bb-bca9-bd430cea88c6 2Gi RWO csi-hostpath-sc 16d
- 백업 작업을 시작하면 Dell EMC PowerProtect Data Manager가 cProxy Pod에 마운트된 임시 백업 스냅샷 영구 볼륨 클레임을 생성합니다. 이 작업을 수행하면 백업 스냅샷이 PowerProtect 어플라이언스로 이동합니다. 이 백업 스냅샷 영구 볼륨 클레임은 소스 영구 볼륨 클레임 스토리지 클래스에 자동으로 바인딩됩니다.
NAME READY STATUS RESTARTS AGE
pod/epco-2021-06-17-11-40-05-epco-mysql-pv-claim-cproxy 1/1 Running 0 5s
pod/wordpress-mysql-5b697dbbfc-gfv9k 1/1 Running 0 17d
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/mysql-pv-claim Bound pvc-d6df4270-dc9e-48bb-bca9-bd430cea88c6 2Gi RWO csi-hostpath-sc 17d
persistentvolumeclaim/pvc-epco-2021-06-17-11-40-05-mysql-pv-claim Bound pvc-4031a452-fd2b-42b1-b1a5-da4df6dc9eb0 2Gi RWO csi-hostpath-sc 6s
- 임시 백업 스냅샷 영구 볼륨 클레임이 다른 스토리지 클래스에 마운트되어 있어야 합니다. 이 요구 사항은 소스 스토리지 클래스에 대한 스토리지 클래스 제한이나 내부 정책으로 인해 발생할 수 있습니다.
다음 단계를 수행하십시오.
- 다음 명령을 사용하여 powerprotect 네임스페이스에 이름이 ppdm-snapshot-storage-class-mapping인 ConfigMap을 생성합니다.
kubectl create cm ppdm-snapshot-storage-class-mapping -n powerprotect
- 다음 명령을 사용하여 ConfigMap을 편집합니다.
kubectl edit cm ppdm-snapshot-storage-class-mapping -n powerprotect
- 편집기가 열립니다. 다음 ConfigMap 예제에서 굵게 강조 표시된 data 섹션을 추가합니다.
apiVersion: v1
kind: ConfigMap
data:
csi-hostpath-sc: debjeet-sc
metadata:
creationTimestamp: "2021-06-04T14:13:17Z"
name: ppdm-snapshot-storage-class-mapping
namespace: powerprotect
resourceVersion: "29682568"
selfLink: /api/v1/namespaces/powerprotect/configmaps/ppdm-snapshot-storage-class-mapping
uid: 74def0f9-207d-4ea5-a9b1-0fca688c7ea5
- 소스 스토리지 클래스 이름과 타겟 스토리지 클래스 이름 간의 매핑을 제공합니다.
단일 ConfigMap에 여러 매핑을 제공하는 경우 다음 시나리오에서는 지원되지 않는 활용 사례와 지원되는 활용 사례를 보여줍니다.
- 지원되지 않는 시나리오: 스토리지 클래스 하나를 서로 다른 두 스토리지 클래스에 매핑할 수 없습니다. 예:
isilon-sc: unity-nfs
isilon-sc: vxflex-sc
- 지원되는 시나리오: 서로 다른 스토리지 클래스를 하나의 스토리지 클래스에 매핑할 수 있습니다.
unity-nfs: isilon-sc
vxflex-sc: isilon-sc
- ConfigMap을 저장합니다. ConfigMap에 나열된 소스 스토리지 클래스 이름에 바인딩된 백업 영구 볼륨 클레임의 경우 백업 스냅샷 영구 볼륨 클레임이 ConfigMap에 나열된 타겟 스토리지 클래스 이름에 바인딩됩니다.
이전 ConfigMap 예에서 소스 스토리지 클래스 이름은 csi-hostpath-sc이고 타겟 스토리지 클래스 이름은 debjeet-sc입니다. 백업되는 영구 볼륨 클레임이 스토리지 클래스 scsi-hostpath-sc를 사용하는 경우 백업 중 스냅샷 영구 볼륨 클레임이 이제 debjet-sc에 바인딩됩니다.
debjeet@irv-ppdm-sdr-140:~$ kubectl get pods,pvc -n exnsNAME READY STATUS RESTARTS AGE
pod/epco-2021-06-17-11-40-05-epco-mysql-pv-claim-cproxy 1/1 Running 0 5s
pod/wordpress-mysql-5b697dbbfc-gfv9k 1/1 Running 0 17d
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/mysql-pv-claim Bound pvc-d6df4270-dc9e-48bb-bca9-bd430cea88c6 2Gi RWO csi-hostpath-sc 17d
persistentvolumeclaim/pvc-epco-2021-06-17-11-40-05-mysql-pv-claim Bound pvc-4031a452-fd2b-42b1-b1a5-da4df6dc9eb0 2Gi RWO debjeet-sc 56s