Storage

So NetApp have entered an agreement to resell Quantum’s Stornext product; this is the next step in their big-data strategy and after the LSI acquisition it makes a lot of sense. There are people who put Stornext in front of NetApp filers and the like but honestly it makes much more sense putting it front of relatively dumb disk like the LSI arrays. The LSI disks in my experience really shine in a clustered file-system and are capable of delivering great throughput but they are not the most feature laden disks that you have ever come across.

It might make an interesting proposition if you could somehow integrate the Stornext filesystem into the filer-heads; this could allow NetApp to overcome some of my current objections to the cluster-mode in OnTap 8.

Perhaps NetApp could go and buy/merge with Quantum and have another go at integrating OnTap with something else? Perhaps go the whole hog and look at pluggable file-system technology in OnTap? Okay, it’s a bit of a science experiment but might be interesting.

The LSI acquistion and now the partnering with Quantum for Stornext is interesting though and it shows that NetApp are finally at the stage where they are confident enough to quietly acknowledge that one size does not fit all; this does not mean that their current products are flawed but it shows a maturity that one should not be trying to bang square pegs into round holes.

It also continues us down the path that storage is software; hardware is just a commodity and should be able to be swapped out and changed with ease.  Another pretty solid move from NetApp.

Steven’s post and a twitter conversation between Storagezilla, W. Curtis Preston and others about archiving, backup, retention and deletion of data bring home some of the realities of data management and policy.

It is often easier to keep data than delete it; this is both a technical issue and an organisational issue. Many applications are not written with good data management in mind; often if you want to scare a developer, ask them how you age data out of their application? Ask them how you might bulk delete data, ask them how you move historical data to an archive and still have it available in some form for reporting purposes?

Organisationally, trying to get an answer out of a Business user how long that they want to keep their data around for is like getting blood from a stone. You will not get an answer and getting them to sign up to any kind of policy which you dictate is next to impossible as well.

So we end up in a situation where it is technically hard to either delete data or archive it and even if we could, we would never get anyone to agree to it anyway. So the default is to keep everything for ever and if you are doing this, the difference between archiving and backup becomes very blurred very quickly.

Now we all know that the right thing to do is to archive, set good retention periods, delete data and we can keep pushing this rock up the hill. And indeed, I would argue that we should but we also need a certain amount of pragmatism.

Archives and backups in many cases have become the same thing; so companies like EMC should not really be castigated for making products which enable this and make the best out of a bad job. But we should as the experts in the field, try where possible to do the right thing; there are cases where doing the right thing is the easiest thing to do, so do it there.

And when someone asks why their backups are taking longer and longer; why they are spending more and more on storage; why their databases appear to have data in which goes back to the dawn of time; you can nod sagely and say ‘Well, you see; backups are not archives but due to business realities, backups have become so but if you really want to move to a better solution, it will require this, this and this…’

I will bet that they will continue to treat backups as archives because to do anything else has become simply too hard. It’s the same old HSM story; it’s too hard…it requires thought and planning, neither of which is overly abundant in today’s IT.

One of the EMC announcements earlier in the year got me thinking; now it might come as a bit of surprise to most of you, I’m really not a glass half-empty kind-of guy and generally try to look at the positive things in most announcements but there was an announcement which really took me aback and almost immediately a cynical ‘point of view’ popped into my mind.

No, it wasn’t the slightly cynical rebrand of Clariion and Celerra into a ‘single’ product called VNX; that was pretty transparent and I’ve never had a real problem with the Frankenstorage, I’m all about the ease of management anyway. As far as I am concerned, you can lash half-a-dozen products together, stick a pretty unified interface on it and as long as I can manage it as a single device; that’ll pretty much do.

No, it was the VMAX announcement. The doubling in performance with a software upgrade; what’s not too like you ask? A performance upgrade for free….well, as long as you have maintenance on the array.

Now if I was a VMAX customer, I might actually be asking another question? Why have I been running my VMAX at half its performance capability for the past year or so? Did I really need all the VMAX kit that I bought and did I need to swell EMC’s coffers by quite so much when I was trying to seriously curtail my IT spend? And am I going to see a similar ‘free’ kicker in performance next year?

It does make one wonder if the VMAX was actually released earlier than intended and before it was really ready.

FAST-2 seemed to take a long time to come to fruition with FAST-1 being a re-brand of Symmetrix Optimizer, a place-holder as opposed to anything really revolutionary?

Was the VMAX Enginuity code release running poorly translated/emulated PowerPC code? And the optimisations are nothing  more than the Enginuity team have actually had time to understand and write a true native Enginuity release?

This is obviously speculation and it probably says a lot that VMAX was still performant even though it was running under-baked code. But if EMC continue to improve VMAX performance without hardware kickers, I’d be looking in their code for sleep statements, timing loops and all other kinds of tricks that programmers pull.

I’ll be watching carefully….

NetApp’s acquisition of the external storage division of LSI yesterday was a bit of a shock; for me, it was who acquired as opposed to Engenio being acquired. I’ve been expecting the acquisition for some time but I was expecting it to be someone like Dell or even IBM but not NetApp.

In general, I think that the acquisition is a good one for the industry; whether it turns out to be a good one for NetApp, time will tell but I suspect it’s a bit of curate’s egg driven by necessity and realism within the NetApp ranks.  But like EMC’s DG acquisition; the benefits will probably be  realised in the longer term.

NetApp are still growing fast that’s for sure but I think that they want to accelerate even more and doing this purely organically is quite hard; you get the feeling when talking to some of the guys that they are pedalling as hard as they can but they are struggling to keep up with themselves.

Also, I think OnTap 8 is the beginning of a story which will long term lead to a very different appliance long-term and one which shockingly may not be completely built on WAFL and RAID-DP. The LSI acquisition is possibly part of the picture.

But there are a few places where LSI makes sense today

Bycast; the combination of Bycast and OnTap appliances is not especially attractive to the core audience for Bycast’s object storage technology at the moment. The costs do not really stack and I wonder if like EMC; NetApp have come to the conclusion that they need some ‘cheap’ and relatively dumb RAID arrays to put behind it. LSI’s disk would fill this role for them very nicely. The DE6900 disk enclosure particularly is made for that sort of application.

High Density Filers; yet again, the DE6900 and Engenio 7900 makes a lot of sense here. If OnTap 8.1 manifests some significant improvements in both aggregate size but also c-mode operation; this sort of density becomes a must. And certainly in the HPC and Media applications which NetApp wants a piece of,  there is a need for this sort of density.

IBM: IBM have sold a lot of nSeries gateways with rebadged Engenio disk; NetApp can get their hands on all of this revenue.  It also means that this relationship could end up being more healthy than it is currently; it could extend the lifetime of the relationship some-what. It may also hasten it’s end!

VNXe: NetApp’s current low-end offering is expensive when compared to the cost of a VNXe. LSI gives NetApp the potential to engineer their own VNXe killer.

Direct Attach: There is still an awful lot of direct attach disk sold; NetApp really don’t have an offering in this space. This will enable them to have the conversation and look at owning the whole of the storage estate.

So there are quite a few reasons to do the deal but….NetApp are not great at acquisition and the Engenio acquisition comes with complexities as it has a rich channel and OEM customers who compete with NetApp. If these relationships are not maintained, the acquisition could quickly turn into a nightmare.

And what happens to the Unified Storage message? That’s not as clear as it was.