1920 ways to improve your life (by migrating to policy-based replication from Global Mirror)

[Guest post by Chris Bulmer, IBM Storage Virtualize Replication and High Availability Architect]

As policy-based replication has been available for roughly 18 months now I find myself regularly discussing the advantages (major performance boosts, far simpler management and no more 1920 events!) and this inevitably leads to the question of “how do I migrate an existing system that’s using Global Mirror?” – so, let’s cover how to do just that!

Firstly, you’ll need to upgrade your systems to 8.6.0 (ideally the latest PTF, which is 8.6.0.3 at the time of writing). This is the first long-term support release that includes policy-based replication, but crucially has some additional functions that will help with the migration.

Secondly, we need to start thinking about volume groups. If you’re using Global Mirror, then you’re likely using consistency groups as these provide mutual consistency for a set of relationships so they have a shared recovery point. Volume groups are not a new feature (introduced circa 2016 if my memory is correct), but they’ve had a lot of attention recently as they play a key part of the overhauled snapshots design, and the logically air-gapped, immutable snapshots that are a key part of IBM’s cyber resiliency offering for primary storage (Barry has covered this before in other posts). Rather than having multiple definitions of what volumes make up an application, policy-based replication uses the same volume group definition. Unlike Global Mirror, there’s no concept of an independent relationship so all replicated volumes will need to be added into volume groups. The natural way to do this will be to create a new volume group and add all the Global Mirror primary volumes from a consistency group into the new volume group, but you can go off-piste if needed and combine or split consistency groups between volume groups.

Here’s where the first of the additional 8.6.0 features are handy. Replicated volume groups need all the volumes in that group to be in the same I/O group and 8.6.0 allows GM primary volumes to be moved between I/O groups (you’ll need to remove the relationship from the consistency group only while you perform the move and it must be in the consistent_synchronized state). If you’re using a single I/O group system then this step isn’t relevant.

And for the second trick, we’ll configure temporary multi-target replication. You’ll need to “upgrade” the partnership on both systems; using the GUI, modify the partnership settings and press the enable policy-based replication button and repeat on the partner. This enables the management capabilities to deal with all of the necessary provisioning for you; IP connectivity on port 7443 is required between systems for this and uses the certificates that you were asked to verify when you pressed the enable button. If you want to use a different system as DR, then create a new partnership instead of upgrading the existing partnership.

Then navigate to the policy-based replication tab, and click on the setup link (I highly recommend you use the GUI for this bit even if you’re a CLI user, as this part is really simple using the GUI). Work through the few steps to configure the systems, link the storage pools and configure the replication policy and then you’re good to go. You’ll need a separate replication policy for each I/O group as it also defines which I/O group to use on the DR system. You can also do this directly from the newly-created volume group.

Assign the replication policy to your newly created volume groups and that will trigger the automatic provisioning on the DR system and start synchronizing the data. Once the synchronization completes, you can delete the Global Mirror relationships and consistency groups, and then you’re done!

If you want the tl;dr version:
1. Upgrade the partnership to support policy-based replication.
2. Non-disruptively move all the volumes in a consistency group to one I/O group.
3. One consistency group at a time, create a volume group and add all the volumes from the consistency group.
4. Create a replication policy (if you don’t have one) and assign it to the volume group.
5. Once the synchronization completes, delete the Global Mirror secondary volumes. Repeat steps 3-6 for each consistency group.

What if you have a disaster during this time?

If the volume group hasn’t yet completed the sync, failover to the Global Mirror secondary volume. To restart replication from the DR system you’ll need to remove the replication policy.

What if you’re using Global Mirror with Change Volumes?

We can’t use the multi-target replication trick if change volumes are being used, but you can convert to regular Global Mirror and remove the primary change volumes. If you’re bandwidth limited and can’t switch to regular Global Mirror, you might consider stopping the relationships to let the volume group synchronize quicker and freeze the recovery point at the DR system for this period.

What if you don’t have enough spare capacity at the DR site for multi-target replication?

You could consider migrating a subset of consistency groups at a time to manage the capacity, or talk to your IBM rep or partner.

I’m using SVC stretched cluster, does this work?

Yes. The only additional thing to note is that you only need to link the pools in site 1 of the mirrored volumes – you don’t need to link the pools in site 2 unless there are non-mirrored volumes in site 2 that you want to replicate.