HDS' announcement yesterday was interesting in that it shows that HDS are beginning to understand that they need to create a buzz about their storage products; HDS' marketing machine has been in the past mostly MIA. However, they seem to have now forgotten that they need a product to hype and sell; the blogosphere and the storage tweets were completely underwhelmed with the HAM announcement, their competitors were underwhelmed and I suspect even their own staff were not exactly jumping with excitement.
The USP range is a good range of arrays and actually in all honesty, it is probably good enough for most customers but it is an aging range and which-ever way you spin it; it needs a refresh (as does the DS8K range from IBM).
The V-MAX may well simply be DMX-V but there are some significant changes and there is a roadmap, both public and NDA, which leads into the future; EMC needs to be held to this and kicked if they fail to deliver. But HDS (and IBM) need a roadmap which challenges EMC at the high-end; we cannot afford to have this become a one horse race.
I am struggling to see at the moment what HAM really gives me that I cannot do already? If I want to mirror across arrays, I can do so; I can do this at the volume manager level. I can also use volume-manager to migrate non-disruptively. These are all things which storage admins and system admins have been doing for years; moving between DAS and SAN, EMC and IBM or HDS at the host level. Sure it's a pain and HAM will make these things easier (at a cost).
But HAM is not going to push EMC to deliver on their promises, it's certainly not going to make them loose sleep. I wish I could be more positive about this but I am struggling like everyone else to make sense of this unless this is part of a series of announcements leading to USP-NEXT.
Martin – points taken. But here is some the rationale as to why we think this release is important. We have received considerable input from our enterprise customers that the ability to migrate data across platforms without disruption and downtime saves significant expense. That is just one key use case, but not the only one, for the value of High Availability Manager. In regards to your comment about USP-V needing a refresh, on what do you base your assertion? Its so long in the tooth that we took away even more market share from our competitors in the last 12 months and are outgrowing EMC (led by our high-end) by 2 to 1 in storage. Sure, everything can be bigger, better, faster, but we have no plans to sit still, I can assure you.
Good dialogue, I look forward to reading more in the future.
If USP-V doesn’t need a refresh today and it is probably good for the next year or two; it will almost certainly need a refresh in the next five years. I would be loathe to put significant investment in an array which is heading towards an end of life.
If we look at the historic technology refresh cycles, USP-V is certainly due a refresh.
I also think it is a mistake to purely focus on EMC; some of the smaller vendors are also capable of disrupting things; especially if they were to be acquired by one of the big boys.
Minimising downtime is indeed important but in my experience; storage array outage is remarkably rare and even to loose a RAID rank; very unusual. I’ve only come close once in the last 15 years. I am not sure that the expense of HAM would really justify itself; might do in some of the financial houses but not for me. I suspect it’s a product which has limited appeal to a small part of a small market.
Application outage is more commonly down to application code failure, performance issues or human error…
Data migration is one of those things which can be done in a number of ways; some more manually intensive than others. Most SAs (both storage and system) have been doing non-disruptive data migrations for some time and I challenge your assertion that you are migrating across platforms, you will be migrating within in a product family which has LUNs from an external array provisioned. At the end of the day, you are still locked in into an array vendor…in this case it’s Hitachi. But it is good that you have at least thought about how to migrate between your own arrays. It’s not entirely unique, there are smaller vendors who at least claim to be able to do non-forklift upgrades and migrations.
I think the problem is…if you run a teaser campaign, you need to have a decent reveal at the end. And the reveal was lacking! HAM fixes some problems but it doesn’t fix those problems which desperately need fixing IMO.
Martin,
The title of your blog says it all – your expectations were set for one thing and you were given another. But just because you wanted “bacon” doesn’t mean that “ham” isn’t useful to those looking for “ham”.
High Availability Manager is extremely useful and just because there is more than one way to do something doesn’t mean that companies shouldn’t keep innovating to provide better approaches. I contend that the way that High Avail Mgr implements data migration is extremely valuable and can save companies tons of money and time while reducing risk. And we both know that host based data migration tools have a ton of limitations. We both also know that storage vendors charge their customers big bucks to do migrations and they use remote replication to perform these moves that are cumbersome, time consuming and prone to error.
The big difference between mirroring and High Availability Manager is that the process is automated, the failover is immediate and there is no application restart. That is a big difference.
One of the key tenants of any technology should be to automate inefficient manual processes.
It isn’t an issue of one or two capabilities that are important but an overall solution that customers embrace. High Avail. Mgr is another capability that makes the USP V more competitive. Trust me – the USP V does keep EMC awake at night.
As far as what the road map is going forward – this announcement in no way impacts what that might or might not be. Two totally separate issues.
Tony, it might come as a surprise to you that I have been doing non-disruptive migrations with no application downtime for many years! Host-based tools are a lot better than a lot of disk vendors like to pretend. And as long as you have a reasonable LVM and operating system, you can do this in a non-disruptive manner.
A year ago we did a large disk consolidation using host-based methods; without a huge amount of vendor involvement and with little service disruption. Some reboots were required but this was an operating system requirement due to legacy levels of drivers/LVMs.
There is also a problem with disk-migration which both approaches have; legacy systems often have many hundred of small LUNs; there is good reason for this and it is often due to performance and laying out for maximum performance. However, the sheer number of LUNs is becoming unmanageable and wasteful, indeed adversely performance impacting in themselves (certainly on a reboot, systems do need rebooting on occasion); having many hundreds of LUNs for example can impact HA take-overs and it means that there is more chance of getting configurations wrong.
So when we migrate between arrays, we often take the chance to look at changing LUN-sizes, reducing LUN counts etc but there is no simple way of doing this. The array is not file-system aware and cannot do the concatenation of LUNs for us; this is a ‘manual process’; it can be scripted but it is pain, however it is pain that can often be taken all at the time of migration.
Data migration is simply more complex than moving from one disk to another these days. I don’t believe that HAM was such a significant improvement that it warranted the attempted marketing campaign it got. It smacked of ‘Oh bollocks, EMC have V-MAX to go and talk to people about, NetApp will have OnTap 8 very soon…we need something new to talk to people about and we aren’t ready with the really new stuff yet!’