#NetApp migration

1 messages · Page 1 of 1 (latest)

rose notch
#

A customer needs to lifecycle their NetApp and therefore migrate all their storage to a newer model.
Apparently, new SVMs will be created.
(That's all I know about their intentions/migration steps so far, but I could get more info if required)

My question now is how such a migration would best be handled with trident?
Perhaps someone else has been in a similar position.

Seeing as LIF IPs and, possibly, the SVM name will change, I'm unsure if just updating the TridentBackendConfig accordingly is sufficient as I suspect that PersistentVolumes will lose their bindings.
(i.e. .spec.csi.volumeAttributes in PVs not matching up anymore)

lean crown
#

the easiest way would be to expand the cluster and move the volumes, then remove the old nodes. If that's not possible or wanted, then use SVM migrate (depends on the protocols used). If you create a new SVM with different IPs, migration is a bit complicated.

#

the first two options run nondisruptively, if you have new IPs then I think you need to shut down all your applications in k8s during the cutover

rotund leaf
#

If you need to handle change backend from Kubernetes perspective, consider using trident protect feature or Astra App DR.