DR replication - targets

[dannyboy99]

Scenario:

Let's say I'm running iSCSI booted systems, with iSCSI mounted LUNs mapped to a Nimble array in a production site. These are bare metal so no hypervisor trickery here - and I'm using array level replication to mirror boot & data to a.n.other location. I have like for like systems at the DR site ready to point to the replicated data and I'm able to fail over the network.

If I have this right, Nimble protects the identity of any given volume by appending a unique array level ID to the end of the target address. At activation time in a DR scenario where I want to repoint my DR kit at the replicated boot and data LUNs, not only will I have to ensure the iSCSI HBA is addressing the revised target ID to get the OS up and running, once booted I'm going to have to remap all the data LUNs once it comes up prior to recovering any applications.

Fully appreciating the dangers of getting this wrong, but if the DR target volumes could assume the originating target ID at time of activation, this would avoid a feverish remapping exercise for whoever picks up the DR exercise (probably at 2am in the morning knowing the way these things go)?

HBA configuration for boot is not really an issue for me - I'm more concerned about OS level software iSCSI connectivity and remapping. In the service provider space, you may not have access at the OS level to engage in remapping LUNs. The more you can do at the infrastructure level for your customer, the better.

If anyone has done something similar on Nimble kit and has a good approach, I'd love to hear from them.

[bgrieve65 · Accepted solution]

Dan,

Replica volumes do not inherit the host initiator group permissions on the DR side. When you promote the DR array in a failover situation (or create a clone to test the volumes for data integrity), you will need to give the appropriate initiator group(s) permission to the mounted volumes/clones. The DR hosts should have a static IQN, which is what you'd use to popular the igroup. Hence, you should be able to create the igroups in advance on the DR array so they are ready in the event of a failover. Once you promote the DR array, you can either manually add the igroup permissions to the volumes or run a script to automate this process.

Does that help at all?

Brandon

[jmonger96]

Hi Dan

You are correct that downstream replica volumes have a different target IQN to the upstream production volumes. Therefore failover will require scripting to change the target's your hosts point at. Your request, to have the same target IQN on downstream replicas, to remove the need to script has been requested before. Please can you engage your local Nimble SE who can add you to internally tracked request. Likewise for any other customers who would like the same functionality.

Just to add to Brandon's reply above, you can add the ACL to the downstream replica prior to failover, however this can only be done via the CLI not through the UI.

Thanks

Jason