Home > Storage > PowerMax and VMAX > Storage Admin > Persistent Storage for Containerized Applications on Kubernetes with PowerMax SAN Storage > CSM for replication
CSM’s replication goal is to allow the implementation of a disaster recovery plan using volume-level replication with SRDF.
Kubernetes and CSI primitives have no awareness of PersistentVolume replication. The CSM for replication aims to expose all the management operations of the volume replication in Kubernetes with the help of custom resource definitions.
For the Kubernetes user, the CSM for replication enables the provisioning of SRDF replicated volumes with a normal PVC directive. The YAML definition for the Persistent Volume Claim is just like a nonreplicated volume. The only requirement is to refer to the StorageClass for the correct mode of replication.
The Kubernetes administrator uses CRD extensions to launch replication operations such as failover, reprotect, failback, and so on.
The CSM for replication for PowerMax takes care of the management and creation of the PV objects of the volume and replicas in the different clusters. It does not manage workload-related resources such as StatefulSet, PVC, ConfigMap, and Secret, and anything else that the containerized application needs to be running.
The different Kubernetes cluster topologies are extensively discussed in the official documentation. In summary, the supported Kubernetes architectures are as follows:
For the current CSM for replication (version 1.2 at the time of this white paper’s release), the following restrictions apply:
For more details on the architecture, see the architecture section of the CSM replication documentation.