Storagebod's Blog

Storage Wars

Is storage the last IT hardware competitive battle-field?

Is it the place where vendors can actually really differentiate between products?

If you look at the server market, pretty much everything comes in flavour of Intel (or AMD) but there's not much between any of them. It's not the hugest hassle to swap an HP environment out for an IBM environment (although listening to some people, you would think the world would come to the end if you were to switch server vendor) and with a hypervisor in the mix; life becomes even easier. When was the last time a start-up became a major player in the server world?

But with storage, there is still everything to play for; start-ups can still get a toe-hold and can still innovate.  The established vendors can knock chunks out of each other without damaging their own product line and I wonder if this is why we see some really quite combative blogging between the vendors. And recently I've noticed the trash-talk stepping up a notch.

Hey, this isn't a plea for everyone to get along but more a plea for more reasoned blogging. Less name-calling and more this is our product and this what it can do for you. More of the 'it works like this' and less of 'company X is rubbish'.

And oh yes; it's great to say what a marvellous place your company is to work but it probably won't make me:

1. Buy your product!

2. Buy your stock!

3. Sell you my stock!

Thoughts from the Twitteratti

@ianhf wondered "Why buy a clariion when baby vmax at same price? (ignoring vmax hype'd 'not ready yet' features)"; various people @davegraham, @storagezilla, @smith_Cameron, @basraayman and myself chipped in.

Ian poses a good question and one which gets asked alot but there's actually a fairly simple answer; the Clariion is a better array for most people! No, architecturally it's not as good; certainly not as reliable and it's replication capabilities are not as good but if I was going to parachute a new EMC array into a non-EMC customer and tell them to get on and manage it; I reckon that most IT shops would have a good chance of getting a Clariion up and working without going through a big training exercise and it'd still be okay in six months. Depending on what software options etc, I reckon there's a good chance that the V-MAX would be a huge mess and unmanageable within six months.

So until EMC can make a V-MAX as simple as a CX to manage; CX has a place but once that happens, then I think Ian has an interesting question. But I would ask the question, if FLARE had replication as good as Enginuity; why would I want a V-MAX? And as they both run on x86 now; why not run FLARE on top of the V-MAX hardware?

With Apologies....

"I'm just a little Blue Tin Cloud
Hovering under the money tree
I'm only a little Blue Tin Cloud
Pay mo' attention to little me
Everyone knows that a Tin cloud
Never costs money, no, not a bit
I'm just floating around over the ground
Wondering where I will fit?"

With IBM's announcement of a Cloud in Can! (And I've been a bit unfair, it's not just tin, it comes with a raft of management software as well) I now have an adequate definition of what Cloud is!!

It's a little bear hanging from a blue balloon, having rolled himself in mud and trying to fool the bees whilst he steals all their money, I mean honey!

Stuff Happens!

Somewhere in the world, there are a bunch of sys-admins, DBAs, application specialists, storage specialists, incident managers, service managers, network specialists and probably a whole bunch of other people running round trying to recover service after a data-centre outage.

How much running around, panic, chaos, shouting and headless chicken mode depends on how much planning, practice and preparedness they have for the event. You might not even notice even if you are using the service because if they have done their work properly, you shouldn't.

Outages happen; big horrible nasty outages happen. In a career which now spans over twenty years, I've been involved with probably half a dozen; from PDUs catching fire due to overload to failed air-conditioning to wrong application of the EPO*. I have been involved in numerous tests; failing over services and whole data-centres on a regular basis and for most of these tests, the end-user would not have been aware anything was happening.

So when Amazon loose a data-centre in their cloud, this should not be news! It will happen, it may be a whole data centre, it may be a partial loss. This not a failure of the Cloud as a concept; it is not even a failure of the public Cloud; there are thousands of companies who host their IT at hosting companies and it's not that different.

What it is a failure of is those companies who are using the Cloud without considering all the normal disciplines. Yes, deploying to the Cloud is quick, easy and often cheap but if you do it without thought, without planning, it will end up as expensive as any traditional IT deployment. Deploying in the Cloud removes much of the grunt-work but it doesn't remove the need for thought!

Shit happens, deal with it and plan for it!

* Emergency Power Off switches should always be protected by a shield and should never be able to be mistaken for a door opening button! But the momentary silence is bliss!

Flying South...

No, I'm not going anywhere; well, not yet! I was hoping for a billion dollar take-over bid from someone in light of some of the goings on in the market. Hey EMC or NetApp, whichever one of you looses out; just throw a billion dollars my way!

Actually, what I'd like to talk about is data migration, with HDS' HAM announcement and the promise of seamless migrations forever; easy and smoothly, it seems a killer feature. Indeed EMC are talking about the same capabilities for the V-MAX. As long as you going from V-MAX to V-MAX, USP-V to USP-V and even IBM SVC to IBM SVC; migrations should be outage free and relatively easy; that's as long as you meet all the pre-requisites with firmwares, driver-levels, multi-pathing software, probably operating system levels; migration will be relatively simple, outage free and automagic!

Of course, as soon as you want to go out of family let's say USP-V -> V-MAX; you've got a problem but as long as you want to keep your disk-controllers the same; you are fine. Yes, I know you can use the USP-V or SVC to bring in external arrays but I am talking about fundamental changes to the storage architecture.

Block-based migration can also be achieved at the host level with minimal to no outage by using host-based tools such as volume managers. It is this technique which is probably most commonly used; it is laborious but it is a well-travelled path. So when it comes to block-level migrations, you have options.

I am assuming that you are not taking the opportunity to re-tier; re-layout for performance, stack LUNs, remove dead data and generally do a tidy-up of your storage environment. You are simply going to move one LUN to another LUN.

However, as we are aware; we don't just have block-storage these days; NAS is becoming the default option for many companies. Management of NAS is generally easier, it can certainly be quicker to provision and it's TCO is often lower. It is an attractive option but....it's a pain to migrate seamlessly and without outage!

In the past, we had data on NAS which probaby did not have the availability requirements of the data sitting on our Tier-1 arrays; it was not mission critical but this is no longer the case; mission critical data sitting on NAS is becoming more common and availability requirements for this data are in the five and six nines levels. Taking outages for migration is will not be acceptable to businesses and we need to come up with strategies for seamless migration of NAS data.

There are tools such Acopia from F5 and Rainfinity from EMC which virtualise at the file-level. Isilon promise no more fork-lift upgrades and you simply incrementally upgrade and migrate; as do others. Or clustered file-systems might be the answer? Perhaps using the facilities in the hypervisor, almost akin to what we do on a host for block?

But this is not yet a mature and well understood discipline for most people. And as NAS becomes de-facto, it will need to be. Also, as NAS has been sold on simplicity, reduced management costs etc; it is going to have to be easy.

Who do I want to win?

So now EMC have entered the bidding for Data Domain; who do I want to win? Actually neither of them, I think I'd prefer someone else to get them!

So why do I want neither of them? Firstly, I must declare that I'm a NetApp and an EMC customer which colours my opinions somewhat.

When it was just NetApp bidding, I was quite content for them to get Data Domain. It strengthened their portfolio and would allow them to compete just a little more with EMC. Now EMC have entered the fray and with a much improved offer; I'm not so keen and NetApp actually getting Data Domain could hamper their ability to compete, it would eat into their cash reserves entirely too much. It would weaken their position and I suspect EMC could force NetApp to significantly overpay if they let hubris get to them.

Also NetApp do not have a great track record of integrating their acquisitions and driving value out of them; so I'd really rather them see to concentrate on building their core and perhaps look different acquisitions. But I think they should have another bid, just to ensure that EMC end up paying a bit more!

Sure, it'd give NetApp an issue competing with a product which they wanted but better that than running out of cash!

However, I really would prefer not to see EMC get Data Domain; EMC do compete with Data Domain in the dedupe space and I'd prefer to see it kept that way. I don't think it would be especially good for the competitive landscape for EMC to get them.

I think I'd prefer HP to pick up Data Domain and although HP really don't need another storage product, I think Data Domain might well fit quite nicely into their line-up. And hey, at least if HP entered the bidding, it might ensure that EMC end up overpaying instead of NetApp.

Oh well, sure is fun sitting on the sidelines. Who's going to be next? I like the idea of Farley become EMC's new star blogger! But that's just for comedy-value!

Enterprise Storage?

Myself and Tony Asaro have had a bit of snit over the uniqueness of the USP-V; he opines that it is unique and I am right that it is not unique. In many ways, this comes down to Tony's opinion that the USP-V is unique because it is the only external storage virtualisation array which is Enterprise Storage. In his opinion neither the v-Series or the SVC are Enterprise Storage and hence do not compete with the USP, DMX and DS8K range. Also in SVC's case because it does not have it's own disk and simply virtualises external arrays; it is not a storage device (I'll leave that comment alone).

So what this really boils down to is what is Enterprise Storage? A couple of years ago, I probably could have sat down and told you what is and what isn't Enterprise Storage but now? I'm not so sure, I can list you some characteristics of Enterprise Storage but the problem is that pretty much all of the arrays from most vendors have those characteristics!

• Highly Available - 99.99%+ available

• Highly Scalable - Supports 500+ disks and supports many hosts attached

• Highly Performant - Whatever that means

• Non-disruptive upgrades - Internal code and hardware can be replaced/upgraded with no service outage

• Supports multiple RAID Levels

• Supports multiple disk-types and sizes within the array

Problem is, as I say pretty much every array from most vendors have these characteristics. So what actually is Enterprise Storage or is it entirely defined by the price you pay? Are some things simply too cheap to be classed as Enterprise Storage?

You see, I'm no longer sure and does it really matter? I suspect it matters alot to the Hitachis and the EMCs of this world but to anyone else? For the rest of us, it probably comes down to the eye of the beholder. Thoughts anyone?