4.011: a bridge to nowhere

Finally.

Almost three years after Hitachi announced its High Availability Manager (HHAM), they have finally delivered introduced the long-promised nondisruptive migration service capability, heretofore to be referred to as The Bridge to Nowhere (BTN).

I mean, seriously, who in their right mind
would want to migrate from one to another Hitachi array… ;0)

Read the press release (and HDS CTO Hu Yoshida's blog post), and you'll be inclined to believe that Hitachi's engineers have one-upped the industry with their latest "capability."

But that would be incorrect, dear reader, for EMC's Federated Live Migration has been delivering zero-downtime migrations to VMAX arrays from prior-generation Symmetrix DMX arrays for over a year. In a race to remain relevant in the face of accelerating competition, Hitachi's engineers have seemingly abandoned the green eggs and ham clustered-array approach to tech refreshing its USP/VSP product line in favor of what is inarguably a direct copy of EMC's FLM.

Well, actually, it's not an exact copy – there are several rather significant deficiencies in Hitachi's nondisruptive migration service (aka the Bridge To Nowhere) as compared EMC's Federated Live Migration. We'll explore these after the break.

 

an imperfect impersonator

Hitachi has a lot of engineers, but they seem to have lost their knack for copying other vendor's innovations of late. Dynamic Tiering is a poor excuse for automated tiering, especially owing to its bloated relocation size (42MB) and slow reaction time to workload changes. They were slow on the uptake for flash drives, and they STILL haven't figure out how to deliver active/active distributed access to LUNs over distance like VPLEX (which is what HHAM was supposed to deliver, if only within a single data center).

So it's no surprise that behind all the marketing hyperbole, the Bridge To Nowhere is, well, both poorly made AND unfinished:

1. The BTN spoofs both the target' (LUN) WWN and the port WWN; FLM only spoofs the target WWN. This is an important difference – Hitachi's approach exploits a security hole in the FC SAN standard, because spoofing the target port ID could be used to maliciously fool the target host into sending its data to an imposter. EMC chose to avoid this exploit.
2. The BTN is sold as a SERVICE, which requires that you hire Hitachi Global Services to provide your migration. FLM is provided to every VMAX customer in the VMAX Migration Package, which itself has a list price of ZERO. The package includes several other migration tools, including Open Replicator/Live Migration for array-based migration from 3rd party storage, Open Migrator for host-based migrations, and a zOS on-line dataset-level migration utility (useful for moving from mod 9's to mod 27's, too) – all at no additional charge with the purchase of any VMAX. With FLM, you can do it yourself; with the BTN you've got to pay extra to have someone do it for you (you can pay EMC to handle your migrations, too, but you don't have to).
3. The BTN still apparently requires host remediation before the migration in order to get the hosts, operating systems, HBAs and device drivers all up to snuff before the nondisruptive migration begins. The problem is, changing OS, HBA or device drivers requires a reboot of the host! That's hardly non-disruptive. EMC relaxed remediation requirements significantly last year – if the host/OS/HBA/driver combination was qualified for use against the current DMX version you are using, then no remediation is required to move that host over to VMAX.
4. The BTN mysteriously does not support HP/UX or AIX hosts under any multi-path driver; FLM supports both when they are running PowerPath. (What's even funnier is that 3PAR's similar offering doesn't support HP/UX hosts either – and HP owns 3PAR!)

If that's not enough, the press releases (and corresponding coverage) would have you believe that Hitachi's new offering will concurrently migrate up to 8 arrays into 1 VSP, never requires a reboot and that it will also automagically transfer over local and remote replication relationships.

FACTS:

• The BTN currently can migrate exactly ONE source array to ONE target VSP at a time – that "8" figure is a promise for the future
• While you can migrate multiple old arrays into a single VSP, each array requires separate dedicated ports on the target VSP. That's the price of spoofing the port WWNs. FLM allows you to migrate as many old DMX arrays (or individual hosts) to the new VMAX as you'd like, and up to 512 individual migration sessions (LUNs) can be underway at any given time.
• To unspoof the BTN requires the hosts to disconnect from the spoofed LUNs, the LUNs and ports to be renamed, and then the hosts can reconnect to the new names.  With FLM, since the ports names don't have to be changed, some hosts can accomplish the unspoof with just an unmount/mount operation.

Finally, nobody has yet automated the migration of replication relationships. The challenge isn't so much the array-side – it's all the scripts that run on hosts that make this difficult. Still, customers are demanding this, and so we can expect that there will be solutions. But I doubt it will ever be truly seamless – unless you really want to live in "spoofed mode" forever…

 

Technorati Tags: EMC,VMAX,Symmetrix,Federated Live Migration,FLM,Hitachi,VSP,USP,nondisruptive,migration,service,bridge to nowhere