Merge branch 'main' into KRV-22364-auth

dell · Oct 15, 2024 · 91c639f · 91c639f
2 parents e2f824d + fbafab9
commit 91c639f
Show file tree

Hide file tree

Showing 9 changed files with 103 additions and 19 deletions.
diff --git a/content/docs/csidriver/features/powermax.md b/content/docs/csidriver/features/powermax.md
@@ -621,7 +621,10 @@ Without storage capacity tracking, pods get scheduled on a node satisfying the t
 
 Storage capacity can be tracked by setting the attribute `storageCapacity.enabled` to true in values.yaml (set to true by default) during driver installation. To configure how often driver checks for changed capacity, set the `storageCapacity.pollInterval` attribute (set to 5m by default). In case of driver installed via operator, this interval can be configured in the sample file provided [here.](https://github.com/dell/csm-operator/blob/main/samples) by editing the `--capacity-poll-interval` argument present in the provisioner sidecar.
 
+## Metro support
+The CSI PowerMax driver supports the provisioning of Metro volumes. The process and details of how to provision and use Metro volumes can be found [here](../../../replication/high-availability).
 
+Please note that the Metro feature does not require the deployment of the replicator sidecar or the replication controller.
 
 ## Volume Limits
 

diff --git a/content/docs/csidriver/features/powerstore.md b/content/docs/csidriver/features/powerstore.md
@@ -29,7 +29,8 @@ kubectl delete -f tests/simple/simple.yaml
 You can use existent volumes from PowerStore array as Persistent Volumes in your Kubernetes, perform the following steps:
 
 1. Open your volume in PowerStore Management UI, and take a note of volume-id. The volume link must look similar to `https://<powerstore.api.ip>/#/storage/volumes/0055558c-5ae1-4ed1-b421-6f5a9475c19f/capacity`, where the `volume-id` is `0055558c-5ae1-4ed1-b421-6f5a9475c19f`.
-2. Create PersistentVolume and use this volume-id in volumeHandle in format <volume-id/globalID/protocol> in the manifest. Modify other parameters according to your needs.
+2. Create PersistentVolume and use this volume-id in volumeHandle in format `<volume-id/globalID/protocol>` in the manifest. In case of Metro volume, the volumeHandle should be in the format `<volume-id/globalID/protocol:remote-volume-id/remote-globalID>`. Modify other parameters according to your needs.
+
 ```yaml
 apiVersion: v1
 kind: PersistentVolume
@@ -759,3 +760,7 @@ Without storage capacity tracking, pods get scheduled on a node satisfying the t
 The attribute `storageCapacity.enabled` in `my-powerstore-settings.yaml` can be used to enabled/disabled the feature during driver installation .
 To configure how often driver checks for changed capacity set `storageCapacity.pollInterval` attribute. In case of driver installed via operator, this interval can be configured in the sample files provided [here](https://github.com/dell/csm-operator/tree/main/samples) by editing the `capacity-poll-interval` argument present in the `provisioner` sidecar.
 
+## Metro support
+The CSI PowerStore driver supports the provisioning of Metro volumes. The process and details of how to provision and use Metro volumes can be found [here](../../../replication/high-availability).
+
+Please note that the Metro feature does not require the deployment of the replicator sidecar or the replication controller.
diff --git a/content/docs/deployment/helm/modules/installation/replication/powerstore.md b/content/docs/deployment/helm/modules/installation/replication/powerstore.md
@@ -91,10 +91,11 @@ kind: StorageClass
 metadata:
   name: "powerstore-replication"
 provisioner: "csi-powerstore.dellemc.com"
-reclaimPolicy: Retain
+reclaimPolicy: Delete
 volumeBindingMode: Immediate
 parameters:
   replication.storage.dell.com/isReplicationEnabled: "true"
+  replication.storage.dell.com/mode: "ASYNC"
   replication.storage.dell.com/remoteStorageClassName: "powerstore-replication"
   replication.storage.dell.com/remoteClusterID: "tgt-cluster-id"
   replication.storage.dell.com/remoteSystem: "RT-0000"
@@ -107,13 +108,17 @@ parameters:
 Let's go through each parameter and what it means:
 * `replication.storage.dell.com/isReplicationEnabled` if set to `true` will mark this storage class as replication enabled,
   just leave it as `true`.
+* `replication.storage.dell.com/mode` points to the replication mode you want to use. It should be one out of "ASYNC", "SYNC" and "METRO". The default value is 'ASYNC'. If mode is set to 'METRO', the driver does not need `remoteStorageClassName` and `remoteClusterID` parameters as it supports METRO with single cluster configuration.
+
+> _**NOTE**_: Metro mode doesn't involve the replication sidecar or the common replication controller, nor does it cause the creation of any replication related custom resources. It just needs the `csi-powerstore` driver.
+
 * `replication.storage.dell.com/remoteStorageClassName` points to the name of the remote storage class. If you are using replication with the multi-cluster configuration you can make it the same as the current storage class name.
 * `replication.storage.dell.com/remoteClusterID` represents ID of a remote Kubernetes cluster. It is the same ID you put in the replication controller config map.
 * `replication.storage.dell.com/remoteSystem` is the name of the remote system as seen from the current PowerStore instance.
 * `replication.storage.dell.com/rpo` is an acceptable amount of data, which is measured in units of time,
-  that may be lost due to a failure.
-* `replication.storage.dell.com/ignoreNamespaces`, if set to `true` PowerStore driver, it will ignore in what namespace volumes are created and put every volume created using this storage class into a single volume group.
-* `replication.storage.dell.com/volumeGroupPrefix` represents what string would be appended to the volume group name to differentiate them. It is important to not use the same prefix for different kubernetes clusters, otherwise any action on a replication group in one kubernetes cluster will impact the other.
+  that may be lost due to a failure. For 'SYNC' mode, RPO will be set to zero by default and not required to be specified. This parameter is not applicable for Metro mode.
+* `replication.storage.dell.com/ignoreNamespaces`, if set to `true` the PowerStore driver will ignore the namespace in which the persistent volume claim resides and put every volume created using this storage class into a single volume group. This parameter is not applicable for Metro mode.
+* `replication.storage.dell.com/volumeGroupPrefix` represents what string would be appended to the volume group name to differentiate them. It is important to not use the same prefix for different kubernetes clusters, otherwise any action on a replication group in one kubernetes cluster will impact the other. This parameter is not applicable for Metro mode.
 
 > _**NOTE**_: To configure the VolumeGroupPrefix, the name format of \'\<volumeGroupPrefix\>-\<namespace\>-\<Cluster Name\>-\<rpo\>' cannot be more than 63 characters.
 
@@ -127,6 +132,7 @@ storage arrays:
 * Cluster `cluster-2` connected to array `RT-0002`
 * Storage array `RT-0001` has a unique ID of `PS000000001`
 * Storage array `RT-0002` has a unique ID of `PS000000002`
+* Replication mode is `ASYNC`
 
 And this is what our pair of storage classes would look like:
 
@@ -137,10 +143,11 @@ kind: StorageClass
 metadata:
   name: "powerstore-replication"
 provisioner: "csi-powerstore.dellemc.com"
-reclaimPolicy: Retain
+reclaimPolicy: Delete
 volumeBindingMode: Immediate
 parameters:
   replication.storage.dell.com/isReplicationEnabled: "true"
+  replication.storage.dell.com/mode: "ASYNC"
   replication.storage.dell.com/remoteStorageClassName: "powerstore-replication"
   replication.storage.dell.com/remoteClusterID: "cluster-2"
   replication.storage.dell.com/remoteSystem: "RT-0002"
@@ -157,10 +164,11 @@ kind: StorageClass
 metadata:
   name: "powerstore-replication"
 provisioner: "csi-powerstore.dellemc.com"
-reclaimPolicy: Retain
+reclaimPolicy: Delete
 volumeBindingMode: Immediate
 parameters:
   replication.storage.dell.com/isReplicationEnabled: "true"
+  replication.storage.dell.com/mode: "ASYNC"
   replication.storage.dell.com/remoteStorageClassName: "powerstore-replication"
   replication.storage.dell.com/remoteClusterID: "cluster-1"
   replication.storage.dell.com/remoteSystem: "RT-0001"
@@ -188,7 +196,7 @@ sourceClusterID: "cluster-1"
 targetClusterID: "cluster-2"
 name: "powerstore-replication"
 driver: "powerstore"
-reclaimPolicy: "Retain"
+reclaimPolicy: "Delete"
 replicationPrefix: "replication.storage.dell.com"
 parameters:
   arrayID:
@@ -197,6 +205,7 @@ parameters:
   remoteSystem:
     source: "RT-0002"
     target: "RT-0001"
+  mode : "ASYNC"
   rpo: "Five_Minutes"
   ignoreNamespaces: "false"
   volumeGroupPrefix: "csi"

diff --git a/content/docs/replication/_index.md b/content/docs/replication/_index.md
@@ -23,7 +23,7 @@ CSM for Replication provides the following capabilities:
 | Asynchronous block volume replication                                                                                               |   yes    |    yes     |    n/a     |    yes    |  no   |
 | Synchronous file volume replication                                                                                                 |   no     |     no     |     no     |    no     |  no   |
 | Synchronous block volume replication                                                                                                |   yes    |     no     |    n/a     |    no     |  no   |
-| Active-Active (Metro) block volume replication                                                                                      |   yes    |     no     |    n/a     |    no     |  no   |
+| Active-Active (Metro) block volume replication                                                                                      |   yes    |     yes    |    n/a     |    no     |  no   |
 | Active-Active (Metro) file volume replication                                                                                       |   no     |     no     |     no     |    no     |  no   |
 | Create `PersistentVolume` objects in the cluster representing the replicated volume                                                 |   yes    |    yes     |    yes     |    yes    |  no   |
 | Create `DellCSIReplicationGroup` objects in the cluster                                                                             |   yes    |    yes     |    yes     |    yes    |  no   |
@@ -50,7 +50,7 @@ the objects still exist in pairs.
 * Stop applications before the planned/unplanned migration.
 * Start applications after the migration.
 * Replicate `PersistentVolumeClaim` objects within/across clusters.
-* Replication with METRO mode does not need Replicator sidecar and common controller.
+* Replication with METRO mode does not need replicator sidecar and common replication controller.
 * Different namespaces cannot share the same RDF group for creating volumes with ASYNC mode for PowerMax.
 * Same RDF group cannot be shared across different replication modes for PowerMax.
 * Replication support for multiple drivers installed on same Kubernetes cluster.

diff --git a/content/docs/replication/high-availability/_index.md b/content/docs/replication/high-availability/_index.md
@@ -0,0 +1,8 @@
+---
+title: "High Availability"
+linkTitle: "High Availability"
+weight: 6
+Description: >
+  Support for High Availability of Volumes
+---
+One of the goals of high availability is to eliminate single points of failure in a storage system. In Kubernetes, this can mean that a single PV represents multiple read/write enabled volumes on different arrays, located at reasonable distances with both the volumes in sync with each other. If one of the volumes goes down, there will still be another volume available for read and write. This kind of high availability can be achieved by using Metro replication mode, supported by PowerMax and PowerStore arrays.
diff --git a/...ent/docs/replication/high-availability.md → ...ation/high-availability/powermax-metro.md b/...ent/docs/replication/high-availability.md → ...ation/high-availability/powermax-metro.md
@@ -1,26 +1,25 @@
 ---
-title: High Availability
-linktitle: High Availability
-weight: 5
+title: PowerMax Metro
+linktitle: PowerMax Metro
+weight: 2
 description: >
   High Availability support for CSI PowerMax
 ---
-One of the goals of high availability is to eliminate single points of failure in a storage system. In Kubernetes, this can mean that a single PV represents multiple read/write enabled volumes on different arrays, located at reasonable distances with both the volumes in sync with each other. If one of the volumes goes down, there will still be another volume available for read and write. This kind of high availability can be achieved by using SRDF Metro replication mode, supported only by PowerMax arrays.
 
 ## SRDF Metro Architecture
 
-![metro architecture diagram](../metro.png)
+![metro architecture diagram](../../powermax-metro.png)
 
 In SRDF metro configurations:
 * R2 devices are Read/Write accessible to application hosts.
-* Application host can write to both the R1 and R2 sides of the device pair.
+* The application host can write to both the R1 and R2 sides of the device pair.
 * R2 devices assume the same external device identity(geometry, device WWN) as the R1 devices.
   All the above characteristic makes SRDF metro best suited for the scenarios in which high availability of data is desired.
 
-With respect to Kubernetes, the SRDF metro mode works in single cluster scenarios. In the metro, both the arrays—[arrays with SRDF metro link setup between them](../../deployment/helm/modules/installation/replication/powermax/#on-storage-array)—involved in the replication are managed by the same `csi-powermax` driver. The replication is triggered by creating a volume using a `StorageClass` with metro-related parameters.
-The driver on receiving the metro-related parameters in the `CreateVolume` call creates a metro replicated volume and the details about both the volumes are returned in the volume context to the Kubernetes cluster. So, the `PV` created in the process represents a pair of metro replicated volumes. When a `PV`, representing a pair of metro replicated volumes, is claimed by a pod, the host treats each of the volumes represented by the single `PV` as a separate data path. The switching between the paths, to read and write the data, is managed by the multipath driver. The switching happens automatically, as configured by the user—in round-robin fashion or otherwise—or it can happen if one of the paths goes down. For details on Linux multipath driver setup, [click here](../../deployment/helm/drivers/installation/powermax#linux-multipathing-requirements).
+With respect to Kubernetes, the SRDF metro mode works in single cluster scenarios. In the metro, both the arrays—[arrays with SRDF metro link setup between them](../../../deployment/helm/modules/installation/replication/powermax/#on-storage-array)—involved in the replication are managed by the same `csi-powermax` driver. The replication is triggered by creating a volume using a `StorageClass` with metro-related parameters.
+The driver on receiving the metro-related parameters in the `CreateVolume` call creates a metro replicated volume and the details about both the volumes are returned in the volume context to the Kubernetes cluster. The Persistent Volume (PV) created in the process represents a pair of metro replicated volumes. When a `PV`, representing a pair of metro replicated volumes, is claimed by a pod, the host treats each of the volumes represented by the single `PV` as a separate data path. The switching between the paths, to read and write the data, is managed by the multipath driver. The switching happens automatically, as configured by the user—in round-robin fashion or otherwise—or when one of the paths goes down. For details on Linux multipath driver setup, [click here](../../../deployment/helm/drivers/installation/powermax#linux-multipathing-requirements).
 
-The creation of volumes in SRDF metro mode doesn't involve the replication sidecar or the common controller, nor does it cause the creation of any replication related custom resources; it just needs a `csi-powermax` driver that implements the `CreateVolume` gRPC endpoint with SRDF metro capability for it to work.
+The creation of volumes in SRDF metro mode doesn't involve the replication sidecar or the common controller, nor does it cause the creation of any replication related custom resources. It just needs the `csi-powermax` driver that implements the `CreateVolume` gRPC endpoint with SRDF metro capability for it to work.
 
 ### Usage
 The metro replicated volumes are created just like the normal volumes, but the `StorageClass` contains some