Skip to content

Commit f7a7c8e

Browse files
authored
PP limitations (#215)
* PP limitations Signed-off-by: Michael Mattsson <[email protected]> --------- Signed-off-by: Michael Mattsson <[email protected]>
1 parent 7b660b1 commit f7a7c8e

File tree

1 file changed

+13
-4
lines changed
  • docs/container_storage_provider/hpe_alletra_storage_mp

1 file changed

+13
-4
lines changed

docs/container_storage_provider/hpe_alletra_storage_mp/index.md

+13-4
Original file line numberDiff line numberDiff line change
@@ -164,6 +164,9 @@ To enable replication within the HPE CSI Driver, the following steps must be com
164164

165165
For a tutorial on how to enable replication, check out the blog [Enabling Remote Copy using the HPE CSI Driver for Kubernetes on HPE Primera](https://developer.hpe.com/blog/ppPAlQ807Ah8QGMNl1YE/tutorial-enabling-remote-copy-using-the-hpe-csi-driver-for-kubernetes-on)
166166

167+
!!! warning
168+
Be understood with the [limitations](#remote_copy_limitations) of the Remote Copy Peer Persistence integration with the HPE CSI Driver before proceeding.
169+
167170
A Custom Resource Definition (CRD) of type `hpereplicationdeviceinfos.storage.hpe.com` must be created to define the target array information. The CRD object name will be used to define the `StorageClass` parameter **replicationDevices**. CRD mandatory parameters: `targetCpg`, `targetName`, `targetSecret` and `targetSecretNamespace`.
168171

169172

@@ -214,10 +217,8 @@ These parameters are applicable only for replication. Both parameters are mandat
214217
</small>
215218

216219
!!! important
217-
218220
Remote Copy groups (RCG) created by the HPE CSI driver 2.1 and later have the **Auto synchronize** and **Auto recover** policies applied. <br /> To add or remove these policies from RCGs, modify the existing RCG using the SSMC or CLI with the following command: <br/ > <br /> **Add** <br /> `setrcopygroup pol auto_recover,auto_synchronize <group_name>` <br/ > **Remove** <br /> `setrcopygroup pol no_auto_recover,no_auto_synchronize <group_name>`
219221

220-
221222
#### Add Non-Replicated Volume to Remote Copy group
222223

223224
To add a non-replicated volume to an existing Remote Copy group, `allowMutations: description` at minimum must be defined within the `StorageClass`. Refer to [Remote Copy with Peer Persistence Replication](#remote_copy_with_peer_persistence_synchronous_replication_parameters) for more details.
@@ -233,8 +234,6 @@ Edit the non-replicated PVC and annotate the following parameters:
233234
!!! note
234235
`remoteCopyGroup` and `oneRcgPerPvc` parameters are mutually exclusive and cannot be added together when editing a `PVC`.
235236

236-
237-
238237
## VolumeSnapshotClass Parameters
239238

240239
These parameters are for `VolumeSnapshotClass` objects when using CSI snapshots. The external snapshotter needs to be deployed on the Kubernetes cluster and is usually performed by the Kubernetes vendor. Check [enabling CSI snapshots](../../csi_driver/using.md#enabling_csi_snapshots) for more information. Volumes with snapshots are immutable.
@@ -390,6 +389,16 @@ spec:
390389
storageClassName: ""
391390
```
392391

392+
## Remote Copy Limitations
393+
394+
These are the current limitations of the Remote Copy Peer Persistence integration with the HPE CSI Driver.
395+
396+
- Only what is considered Classic Peer Persistence is supported. Active/Active hostset proximity is not supported.
397+
- Peer Persistence does not provide disaster recovery for workloads running on Kubernetes. Peer Persistence provide disaster recovery for the storage system.
398+
- Peer Persistence only provide data path resilience. If the primary array is unreachable for the CSP or the role of the remote copy group has changed due to disaster recovery operations (manual or automatic switchover/failover), all CSI operations will cease to function until the primary array comes back up and the role of the remote copy groups returned to original state.
399+
- When the primary array is unavailable for the Kubernetes cluster and remote copy group has failed over to the secondary array successfully, running workloads will continue to run if the host the workload was running on has redundant data paths to the secondary array (current primary array).
400+
- It's possible to access volumes from the secondary array by [statically provisioning](#static_provisioning) `PersistentVolumes` without renaming the volume on the array. This is only safe if it has been determined that the primary array does not have active hosts accessing the volume against the primary array.
401+
393402
## Support
394403

395404
Please refer to the HPE Alletra Storage MP, Alletra 9000 and Primera and 3PAR Storage CSP [support statement](../../legal/support/index.md#hpe_primera_and_hpe_3par_container_storage_provider_support).

0 commit comments

Comments
 (0)