AnsweredAssumed Answered

DR replication - targets

Question asked by Dan Keating on May 3, 2014
Latest reply on Feb 10, 2016 by Jason Monger


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.