« 4.010: when lightning strikes | Main | 5.001: vspex, vblock and enterprise clouds »

February 27, 2012

4.011: a bridge to nowhere

imageFinally.

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…

 


TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834c659f269e20168e80c0b5d970c

Listed below are links to weblogs that reference 4.011: a bridge to nowhere:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

The comments to this entry are closed.

anarchy cannot be moderated

about
the storage anarchist


View Barry Burke's profile on LinkedIn Digg Facebook FriendFeed LinkedIn Ning Other... Other... Other... Pandora Technorati Twitter Typepad YouTube

disclaimer

I am unabashedly an employee of EMC, but the opinions expressed here are entirely my own. I am a blogger who works at EMC, not an EMC blogger. This is my blog, and not EMC's. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.

search & follow

search blogs by many emc employees:

search this blog only:

 posts feed
      Subscribe by Email
 
 comments feed
 

 visit the anarchist @home
 
follow me on twitter follow me on twitter

TwitterCounter for @storageanarchy

recommended reads

privacy policy

This blog uses Google Ads to serve relevant ads with posts & comments. Google may use DoubleClick cookies to collect information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide ads about goods and services of interest to you. If you would like more information about this practice and your options for not having this information used by Google, please visit the Google Privacy Center.

All comments and trackbacks are moderated. Courteous comments always welcomed.

Email addresses are requested for validation of comment submitters only, and will not be shared or sold.

Use OpenDNS