1. Non-disruptive migration of data (within an array, across array, within the federation…)
2. Non-disruptive upgrade of the migration technology itself.

I believe both these points are important, but just mixing them together under a “data migration” topic may not be the best way to describe the issues.

1. Non-disruptive migration of data (within an array, across array, within the federation…)
2. Non-disruptive upgrade of the migration technology itself.

I believe both these points are important, but just mixing them together under a “data migration” topic may not be the best way to describe the issues.

Hardware intermix (e.g. 2145-8F2 and 2145-8G4) is permitted, dependent on software support. So long as all your 2145-8F2’s and 2145-8G4’s are running the same 4.3.x, or newly introduced nodes are at a lower version, it’s the same as adding nodes. Taking 2145-4F2’s to 2145-8G4’s is as simple as adding the new hardware to the cluster, then removing the old hardware. This is covered in “Implementing the IBM System Storage SAN Volume Controller V4.3” (SG246423), Appendix D. This actually removes the need to migrate between clusters in many cases, since typically a cluster migration is done for hardware refresh.
Node migration remains fully non-disruptive; it consists of changing the VDisk’s preferred IO Group. Migration between arrays and spanned arrays also remains fully non-disruptive with fail-back, as VDisk extents are copied during migration instead of being moved. This eliminates the need for any quorum during migration, because it’s a copy operation. Software upgrade is fully non-disruptive with improved fail-back from 4.2 onward – if nothing else, the SVC team learns from their mistakes quickly.

But let’s say you need to do a cluster migration due to capacity or performance issues. This is what I’d call “90% non-disruptive.” From the SVC side, it is an entirely non-disruptive operation. The disruptive side actually comes from the host. On the SVC, you simply create a Metro mirror of the data to be migrated between clusters. But this presents an exactly identical disk to the host twice, which obviously doesn’t work. To complete the migration, you need to stop IO, switch the mirror direction, and remount from the new cluster. Typically, it translates to 5-15 minutes of downtime at the host. However, from the perspective of the SVC, it’s entirely non-disruptive. But again, if you’re only doing a hardware upgrade, it’s unnecessary.

Certainly the SVC is not without its limitations and problems at times – like David, I know of an institution that experienced a multi-day outage due to difficulties during an upgrade. However, their outage occurred not due to design flaws, but rather an edge case bug. If we include those situations, there isn’t a vendor out there I haven’t heard of causing major outages or data loss. We like to cover absolutely all our bases – what about hardware failure? What if the power fails? What if, what if, what if? But as the complexity of storage has grown by leaps and bounds, it’s simply impossible to cover absolutely every possible failure scenario.

The ultimate limitation of the SVC is the storage behind it and the host in front of it, because it’s not storage itself. IBM is notoriously bad at explaining this. If you need to do a firmware upgrade on a DS4k behind an SVC, you must offline the disks at the SVC or shut down the SVC, because the DS4k is disruptive. If you have an AMS2500 behind it, the opposite becomes true – firmware is non-disruptive. A failure in your storage can and will result in problems at the SVC.

Standard Disclaimer: I’m not an IBM employee, and IBM still isn’t giving me free stuff.