CSI statically provisioned volumes with PowerMax usage

Most organizations will use dynamically provisioned PVCs with Kubernetes and Kubevirt.
And a Replication and DR offering is available from Dell that supports all of the dynamically provisioned volumes with array-based replication and DR orchestration.

For once client, however, they are considering migrating from VMware to OpenShift Virtualization, and currently use RDMs and wish to Migrate to VMware.  Also, their established DR process relies on SRDF replication, failover, and mapping the volumes up to a dedicated set of VMs used for Disaster Recovery.

• migration into OpenShift Virtualization from VMware, by remapping the RDMs to statically provisioned PVCs and into migrated VMs.
• Externally controlled remote replication automation with Ansible.  And “Data DR”, attaching to dedicated set of VMs in the DR cluster

CSI Static Provisioning will work well for this case.  “Statically provisioned” in this case is a fancy way of saying “the volumes already exist”.

I hope this showcase is informative.  It should detail some of the expected configuration requirements.
Here we go:

For starters, we have existing volumes that reside in one or more storage groups in a PowerMax.

(6) volumes, each 22 GB in size in a storage group intended to represent R1s in an RDF storage group

 

To use CSI static provisioning, the CSI driver validates both the PowerMax Device ID and the volume name.

Each volume will require a 10 digit uuid:

[root@rhel84 demo-files]# uuidgen | cut -d'-' -f5 | cut -c1-10

ec3aee840e

 

change the volume label on the array in the format:

csi-<Cluster Prefix>-<Volume Prefix>-<Volume Name>

Create your PV and PVC objects

 

The PV spec.csi.volumeHandle for PowerMax is in the format of

csi-<Cluster Prefix>-<Volume Prefix>-<Volume Name>-<Symmetrix ID>-<Symmetrix Volume ID>

 

“csi” is a hardcoded value

Cluster Prefix is set during the CSI driver installation (driver in the variable named clusterPrefix)

Volume Prefix is set during the CSI driver installation (driver in the variable named volumeNamePrefix)

VolumeName is a random 10 character UUID that the CSI controller pod, provisioner sidecar generates for dynamically provisioned PVs;  for statically provisioned PVs use uuidgen and grab the last 10 characters

>> the VolumeName attribute on the PV object seems to be constructed with the prefix ‘pmax-‘ which is not part of the volumehandle:  pmax-ec3aee840e

Symmetrix ID is the 12 digit PowerMax Serial Number

Volume ID is the LUN (device) ID

 

PV should be set to persistentVolumeReclaimPolicy: Retain this way the CSI driver doesn’t attempt to delete the PowerMax LUN when deleting the K8s PV object.

Reference your local storageclass; or have a dedicated storageclass for statically provisioned PVs

 

The example below shows a volumeMode: Filesystem PV with fsType: ext4 however OpenShift Virtualization disks will use volumeMode: Block with accessModes: ReadWriteMany

create the PVCs in the desired namespace.  The PVC name does not have any Dell requirements.

---

apiVersion: v1

kind: PersistentVolume

metadata:

  name: pmax-ec3aee840e

spec:

  capacity:

    storage: 22Gi

  accessModes:

    - ReadWriteOnce

  persistentVolumeReclaimPolicy: Retain

  storageClassName: powermax-sc

  volumeMode: Filesystem

  csi:

    driver: csi-powermax.dellemc.com

    volumeHandle: csi-CSM-csivol-ec3aee840e-000120001688-007B1

    fsType: ext4

---

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: fio-log-pvc-sp

  namespace: default

spec:

  volumeName: pmax-ec3aee840e

  storageClassName: powermax-sc

  accessModes:

  - ReadWriteOnce

  resources:

    requests:

      storage: 22Gi

[root@rhel84 demo-files]# oc apply -f 00-static-pv.yml

persistentvolume/pmax-ec3aee840e created

persistentvolumeclaim/fio-log-pvc-sp created

I used a native container mount for testing statically provisioned PVCs.

---

apiVersion: v1

kind: Pod

metadata:

  name: fio-control

  namespace: default

spec:

  volumes:

  - name: logvol

    persistentVolumeClaim:

      claimName: fio-log-pvc-sp

  containers:

  - name: fio-control

    image: quay.io/dan_cohen/fio:latest

    command: ["/bin/bash", "-c"]

    args: ["sleep 86400s"]

    volumeMounts:

    - name: logvol

      mountPath: /logs/

The Pod comes up, and the CSI driver facilitates the volume mounting

In the process, The Dell CSI driver manages the volume mapping and device configuration (multipathing, etc) on the host.

007B1 exists in the ‘RDF SG group’ and the CSI driver also manages the device presentation in another SG it uses for host presentation.

Everything in OpenShift can be successfully cleaned up / deleted.
The device persists in the RDF group and the SRDF replication can be controlled externally.

Dell offers a DR solution with CSM Replication to complement the Dell CSI drivers with supporting Disaster Recovery solutions for Kubernetes.  This write up highlights another way that a client plans to approach a segment of their workloads.