Scenario

Suppose you have two (or more) datacenters and you’re running a true active / active setup, meaning that clusters are spread over both sites and each host has access to both the local volume as well as the identical writable copy on the second site. You’ve accomplished this by setting up ActiveCluster and some PODs with volumes in them and everything is working fine and the PODs are in sync, so volumes can be written to on both locations.

The OTA team is testing a new application on one of the sites without the cluster being spread over both sites. When the testing is done it’s time to go to production and move the application to a production cluster, so formerly local volumes need to be added to a POD, because they need to be written to on the second location as well (or simply need to be replicated to the DR site to have the data on two locations).

Moving one or more volumes to a POD – steps

In order to move one or more volumes into PODS, you can either create a new unstretched POD or – and this can be tricky – you need to unstretch an existing POD first. If a POD contains volumes that are actually being accessed on both sites, you need the hosts to stop using the volumes on the array that’s going to be deleted from the POD for a short while. When hosts are configured correctly (having access to each volume on two arrays), you don’t need to take any action as the I/O will automatically be redirected to the only surviving Pure array. Of course this only applies to the hosts that are actively acessing volumes in the remote POD that you want to unstretch; hosts on the “surviving” array will continue to access that array and will not be able to access the volumes on the second site for a short while. Stopping I/O is necessary because when unstretching PODs, one side loses all access to the volumes in that particular POD.

If hosts are not configured to access volumes on both sites, you will need to failover the resources to the surviving site. When no I/O is going to the array that doesn’t contain a copy of the OTA volumes, the POD that will contain these formerly OTA volumes will need to be unstretched.

If this POD contains a large number of volumes, there’s something interesting to be seen later on! Pay attention!

When you’re sure all I/O to volumes in the POD on the second array is stopped or multi-site access is configured correctly, you can start unstretching the POD: select the POD, delete the remote array as seen from the volume(s) that you need to add to that POD and as soon as the POD contains only 1 array, you can add the volumes that need to be present on both sites.

Resyncing

When all OTA volumes in our example are added to the unstretched POD, you can add the remote Pure array and the resyncing will start.

Depending on the activity on the volumes in that POD, this can be a short transition or somewhat longer (sometimes even hours if it’s a really active POD), but there’s one interesting thing that I noticed during the numerous resyncing activities that I’ve whitnessed so far: when the resync starts, it looks like it’s taking ages to get somewhere and it might even show a disappointing progress, until the resync reaches 20%.

All of a sudden the resync will look like it’s speeding up and as soon the the counter is over 20% it will reach 100% in a matter of seconds (or minutes). I cannot find any proof that this progress has a different meaning other than what it looks like: 20% meaning only 20% is actually resynced, but my assumption is that 20% means it reached 100% and above 20% means it’s catching up on the last few “dirty” blocks on the sides that are being written to.

The good thing is that as soon as you realize that 20 is the new 100%, so waiting for the resync isn’t half as bad as it looks at first!

Happy resyncing, everybody!