Operation: No Data Left Behind

Recently, a colleague sent me an industry article about a beleaguered health insurance provider that is Down Under in more ways than one (“Medibank Still Struggling with Data Migration Headache”). I’ll spare you the gory details, but suffice it to say that when your CEO publicly calls your latest data snafu “unacceptable,” you probably shouldn’t spend your Christmas bonus early.

I don’t have the specifics on Medibank’s case (obviously, they’re not a Cirrus customer), but the problem they’re facing is sadly one that we’ve seen many times before: unexpected outages caused by (presumably) a badly planned migration. Before you rush to judgment in Medibank’s case, however, it’s not easy to adequately plan for something as complex as a data migration, especially when you’re using legacy methods to do it. For example, using legacy tools like host-based mirroring or pressing your disaster recovery/restore tools into service require manual detail mapping for each host, tracing the dependency of each disk to each SAN fabric and storage frame, and repeating that process for each host-to-storage path. Compounding the problem, different OS platforms and storage systems each have their own unique discovery process. You need to be an expert just to do the pre-planning discovery correctly and, even if you do nail the discovery and planning stages, accidents and human error can still undermine the process.

Golden Spreadsheet or Fool’s Gold?
Because of the inherent complexity in data migrations, IT departments often look for shortcuts. The “golden spreadsheet” is a good example. Every IT department has one: a supposedly authoritative spreadsheet that contains all of the storage-to-host allocations. IT departments soon realize, however, that not all that glitters is gold. A set of LUNs (logical unit numbers) is lost or migrated to the wrong SAN fabric and suddenly you have an “unacceptable” problem that could even result in that most dreaded of migration scenarios, data loss.

For all of the above reasons, we set out at Cirrus Data to create a new gold standard for data migration: the Data Migration Server (DMS). DMS’ auto-discovery feature automatically generates accurate, detailed information on an enterprise’s SAN topology, LUNs, FC ports, switches (no matter how complex the network design), and all of the connections between them. DMS reduces the complex issue of pre-migration discovery and planning down to a simple eyeballing of the discovered resources and a quick comparison against the golden spreadsheet. (It also corrects the errors in your golden spreadsheet before anyone notices, which is worth its weight in gold right there.)

I could rattle off any number of case studies to show you how DMS is different, but I wouldn’t need to go any further than our first customer. It was on a Saturday in September, and we had just rolled up to the customer’s loading dock with a pair of DMS-4000s in tow (actually, they were pretty small, even back then). We arrived at 10:00 AM prompt and left at 1:02 PM with all of the migration sessions completely set up. In between those 182 minutes were 101 minutes of waiting for the customer to create and assign new destination LUNs (despite the fact that we had asked them to do that ahead of time, but you know how that goes…), 32 minutes of identifying and labeling the auto-discovered LUNs (which would have taken only a few seconds if they had pre-prepared the text file as we had asked, but which got the same response as our other request) and about eight minutes of hellos, goodbyes, and elevator rides. So it only took 41 minutes to rack the DMS-4000s, power them up, connect the cables, update the software, insert them the customer’s fibre channel fabric, and create the migration sessions. As for the migration of the LUNs, that only required five minutes of cutover time with the DMS—but it took the customer weeks to find those five minutes. When the cutover was complete, the application owners expressed their amazement; they weren’t even aware the migration process had started, let alone been completed.

That was over four years ago. Today, we’ve just finished releasing DMS version 4 into the market with some significant enhancements. For example, remember that 101 minutes needed to create and assign new LUNs in the example above? DMS v4’s auto-allocation feature now does that automatically in seconds. The latest version of DMS also features robust support for data migrations into the cloud, including Amazon Web Services, Microsoft Azure, and IBM’s SoftLayer.

All by way of saying that no company should have to go through the painful process that Medibank is undergoing right now. With the right tools, the discovery and planning process can be greatly simplified and the execution process automated to reduce errors. Because data migration shouldn’t mean migrating to another part of the world under an assumed alias to escape angry customers.