Replication

Starting with Container Storage Module 1.12, all deployments will use images from quay.io by default. New release images will be available on Docker Hub until CSM 1.14 (May 2025), and existing releases will remain on Docker Hub.

The installation process consists of two steps:

  1. Install Container Storage Modules (CSM) for Replication Controller
  2. Install CSI driver after enabling replication

Before you begin

Please read this document before proceeding with the installation. It provides detailed steps on how to set up communication between multiple clusters which will be required during or after the installation.

Install Container Storage Module Replication Controller

You can use one of the following methods to install Container Storage Module Replication Controller:

  • Using repctl
  • Installation script (Helm chart)

We recommend using repctl for the installation, as it simplifies the installation workflow. This process also helps configure repctl for future use during management operations.

Using repctl

Please follow the steps here to install & configure Dell Replication Controller using repctl.

Using the installation script

Please follow the steps here to install & configure Dell Replication Controller using script.

(Optional) FQDN Setup

If Container Storage Module Replication is being deployed using two clusters in an environment where the DNS is not configured, and the cluster API endpoints are FQDNs, it is necessary to add the <FQDN>:<IP> mapping in the /etc/hosts file in order to resolve queries to the remote API server. This change will need to be made to the /etc/hosts file on:

  • The environment that is performing the installation/management (wherever repctl or the install script is used).
  • Both dell-replication-controller-manager deployments.
    • To update the dell-replication-controller-manager deployment, execute the command below, replacing the fields for the remote cluster’s FQDN and IP. Make sure to update the deployment on both the primary and disaster recovery clusters.

      kubectl patch deployment -n dell-replication-controller dell-replication-controller-manager \
      -p '{"spec":{"template":{"spec":{"hostAliases":[{"hostnames":["<remote-FQDN>"],"ip":"<remote-IP>"}]}}}}'
      

Install CSI driver

Please follow the steps outlined in CSI Driver page during the driver installation. Please follow the steps outlined in PowerFlex, PowerMax, PowerScale, PowerStore page during the driver installation.

Note: Please ensure that replication CRDs are installed in the clusters where you are installing the CSI drivers. These CRDs are generally installed as part of the Container Storage Module Replication controller installation process.

Dynamic Log Level Change

Container Storage Module Replication Controller can dynamically change its logs’ verbosity level. To set log level in runtime, you need to edit the controllers ConfigMap:

  
kubectl edit cm dell-replication-controller-config -n dell-replication-controller

And set the CSI_LOG_LEVEL field to the level of your choosing. Container Storage Module Replication controller supports following log levels:

  • “PANIC”
  • “FATAL”
  • “ERROR”
  • “WARN”
  • “INFO”
  • “DEBUG”
  • “TRACE”

Note: CSI-Replicator sidecar utilizes the same log level as CSI driver. To change the sidecars log level refer to corresponding csi drivers documentation.


Replication Enabled Storage Classes

In order to create replicated volumes & volume groups, you need to add some extra parameters to your storage class definition. These extra parameters generally carry the prefix replication.storage.dell.com to differentiate them from other provisioning parameters.

Replication enabled storage classes are always created in pairs within/across clusters and are generally mirrors of each other. Before provisioning replicated volumes, make sure that these pairs of storage classes are created properly.

Common Parameters

There are 3 mandatory key/value pairs which should always be present in the storage class parameters:

replication.storage.dell.com/isReplicationEnabled: 'true'
replication.storage.dell.com/remoteClusterID: <RemoteClusterId>
replication.storage.dell.com/remoteStorageClassName: <RemoteScName>

remoteClusterID

This should contain the Cluster ID of the remote cluster where the replicated volume is going to be created. In the case of a single stretched cluster, it should be always set to self.

remoteStorageClassName

This should contain the name of the storage class on the remote cluster which is used to create the remote PersistentVolume.

NOTE: You still need to create a pair of storage classes even while using a single stretched cluster.

Driver specific parameters

Please refer to the driver specific sections for CSI Driver for a detailed list of parameters.

Driver specific parameters

Please refer to the driver specific sections for PowerMax, PowerFlex, PowerStore, PowerScale for a detailed list of parameters.

PV sync Deletion

The dell-csm-replicator supports ‘sync deletion’ of replicated PV resources i.e when a replication enabled PV is deleted its corresponding source or target PV can also be deleted.

The decision to whether or not sync delete the corresponding PV depends on a Storage Class parameter which can be configured by the user:

replication.storage.dell.com/remotePVRetentionPolicy: 'delete' | 'retain'

If the remotePVRetentionPolicy is set to ‘delete’, the corresponding PV would be deleted.

If the remotePVRetentionPolicy is set to ‘retain’, the corresponding PV would be retained. This is not applicable for file system replication.

By default, if the remotePVRetentionPolicy is not specified in the Storage Class, replicated PV resources are retained.

RG sync Deletion

The dell-csm-replicator supports ‘sync deletion’ of RG (DellCSIReplicationGroup) resources i.e when an RG is deleted its corresponding source or target RG can also be deleted.

The decision to whether or not sync delete the corresponding RG depends on a Storage Class parameter which can be configured by the user.

replication.storage.dell.com/remoteRGRetentionPolicy: 'delete' | 'retain'

If the remoteRGRetentionPolicy is set to ‘delete’, the corresponding RG would be deleted.

If the remoteRGRetentionPolicy is set to ‘retain’, the corresponding RG would be retained.

By default, if the remoteRGRetentionPolicy is not specified in the Storage Class, replicated RG resources are retained.

Example

If you are setting up replication between two clusters with ClusterID set to Cluster A & Cluster B, then the storage class definitions in both the clusters would look like:

Cluster A

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rep-src
parameters:
  replication.storage.dell.com/isReplicationEnabled: "true"
  replication.storage.dell.com/remoteClusterID: ClusterB
  replication.storage.dell.com/remoteStorageClassName: rep-tgt
  # Some driver specific replication & non-replication related params
provisioner: csi-powermax.dellemc.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

Cluster B

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rep-tgt
parameters:
  replication.storage.dell.com/isReplicationEnabled: "true"
  replication.storage.dell.com/remoteClusterID: ClusterA
  replication.storage.dell.com/remoteStorageClassName: rep-src
  # Some driver specific replication & non-replication related params
provisioner: csi-powermax.dellemc.com
reclaimPolicy: Delete
volumeBindingMode: Immediate