次の手順に従って、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
- アプリケーション ネームスペースは、たとえば、最初のストレージ クラスを使用します。
debjeet@irv-ppdm-sdr-140:~$ kubectl get pods,pvc -n exns
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ポッドにマウントされる一時的なバックアップ スナップショットの永続ボリューム要求を作成します。このアクションでは、バックアップ スナップショットをPowerProtectアプライアンスに移動します。このバックアップ スナップショットの永続ボリューム要求は、ソース永続ボリューム要求ストレージ クラスに自動的にバインドされます。
debjeet@irv-ppdm-sdr-140:~$ kubectl get pods,pvc -n exns
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
- ソース ストレージ クラス名とターゲット ストレージ クラス名間のマッピングを指定します。
1つのConfigMapに複数のマッピングを指定する場合、以下にサポートされていないシナリオとサポートされているシナリオを示します。
- サポートされていないシナリオ：1つのストレージ クラスを2つの異なるストレージ クラスにマッピングすることはできません。例：
isilon-sc: unity-nfs
isilon-sc: vxflex-sc
- サポートされているシナリオ：異なるストレージ クラスを1つのストレージ クラスにマッピングできます。
unity-nfs: isilon-sc
vxflex-sc: isilon-sc
- ConfigMapを保存します。ConfigMapにリストされているソース ストレージ クラス名にバインドされているバックアップ永続ボリューム要求の場合、バックアップ スナップショットの永続ボリューム要求は、ConfigMapにリストされているターゲット ストレージ クラス名にバインドされます。
前例のConfigMapを使用すると、ソース ストレージ クラス名はcsi-hostpath-scで、ターゲット ストレージ クラス名はdejeet-scです。バックアップ中の永続ボリューム要求がストレージ クラスcsi-hostpath-scを使用している場合、バックアップ中のスナップショット永続ボリューム要求はdebjeet-scにバインドされるようになります。
debjeet@irv-ppdm-sdr-140:~$ kubectl get pods,pvc -n exns
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 debjeet-sc 56s