Cluster Swap

[Paul Gazzara]

Does anyone know where I can find documentation on doing a cluster swap? I have a new starter san coming in and would like to just swap the cluster to the new hardware.

[Patrick Terlisten]

Hello,

what kind of harwdare do you currently use and what hardware will you receive?

Regards,
Patrick

[Paul Gazzara]

I currently have an IBM 3650 1.8Tb running San/IQ 8.1 and a NSM 2060 1.8TB running San/IQ 8.1. We will be receiving a P4300 G2 7.2TB starter san. I assume it will have 8.5 on it.

[Patrick Terlisten]

Hello Paul,

I'm not a LH crack, but remote snapshots would be a solution.

Regards,
Patrick

[Bryan McMullan]

You could just add the new units to the cluster and allow everything to restripe. Then remove the old IBM from the management group and allow it to restripe again.

Beyond that, like Patrick said. Snapshot the volumes from the old cluster to the new one. Then get a maintenance window, do one final snapshot where there are no new changes, promote the volumes to primary, and finally change all your iSCSI initiators to point to the new cluster (and assign volume access within the cmc).

[Alaric Turner]

If you are using this for only as an ESX target you could create a new parallel SAN & then storage Vmotion the machines accross

[Paul Gazzara]

Thanks, however we do have some iSCSI connections from some servers along with ESX hosts.

[Mike Povall · Accepted solution]

The other option is to add the two new P4500 G2 units to the existing management group, create a new cluster within the existing management group with a new VIP and then edit the volume that you want to move changing the cluster entry to that of the new cluster.

SAN/iQ will then move the volume in the background while your servers remain attached to it. You will need to amend any iSCSI initiators so that they reference the new cluster going forward but the iSCSI connection will remain in operation following the move of the volume.

Once all of the volumes have been moved over then you can either reprovision the original storage as second tier or remove the cluster completely and decommission it.

Regards, Mike.

[Bryan McMullan]

@Mike

We've had issues with that type of move with high transaction loads (like SQL Server volumes). So there may be a momentary drop when you move to the new cluster. (Enough of a drop to anger SQL.) While the same drop was there for fileshares and the such, they seem to be a lot more forgiving during the cluster migration.

[Paul Gazzara]

Mike, Bryan that is exactly what I was after. Thanks for the info this and I think this will be the method I will use.