Storagebod's Blog

Just a quick thought...

Everything can break, you need to remind yourself this whenever a vendor is talking to you. 

Over the past year, I have personally come across the following:

    1) A triple disk failure in a RAID6 environment which resulted in data loss

    2) Data-loss due to an a bug on an array

    3) Data-loss due to an application bug

    4) Data-loss due to failed back-ups

Of these, only the first three are in anyway partially excuseable. Hardware will fail, software inevitably has bugs; we would hope that in general that all scenarios are tested but anyone who has been involved in testing knows that sometimes things get concessioned or sometimes simply missed. 

But the last one is pretty much inexcusable, failed back-ups should be caught and fixed before they become a problem. The only acceptable SLA/OLA for a back-up environment is 100%; if you are willing accept that there is a chance that you might loose that data, perhaps you shouldn't be backing it up in the first place. 

Duck the bullets....

Chris Mellor's blog entry about the 'The Storage Array Killing Fields' and Scott Lowe's entry on 'The Future of NetApp' touch on very similar areas; what is the future of storage array manufacturers and in Scott's case, what is the future of a specific array vendor but many of Scott's points can be applied to any number of storage vendors.

So what is the future of the storage array? Are storage arrays even relevent today? This is a question which is going to be increasingly asked as we move towards a commodity based approach; it has wide reaching implications for the storage array vendors. Of course, when we talk about the future; what horizon are we talking about? 2 years, 5 years or even 15 years? 

I suspect the short-term future of the storage array, certainly the next 2 years is probably fairly rosey. Demand for storage is strong and the general herd are not yet transitioning to dynamic, commodity-based data centres. If you are storage array vendor, you should be able to continue to make hay. But I think that you only have to look at the high-end array market to see some interesting trends.

VMAX? VMAX almost stands by itself at the moment; there are no real competing products in the market today. Huh? What about HDS and IBM? Well, HDS are due a refresh of the USP and then I suspect that V-MAX has a real competitor in that space. IBM however, really don't want to sell you DS8K unless you are a mainframe shop. IBM are no longer that interested in the high-end array; if you are a non-mainframe shop, they will try to sell XIV and they will do some interesting things to do so.

I do not expect HDS, EMC or IBM to vacate this space until the mainframe dies but the reality is that for most IT shops, the high-end array is probably not where they want to be; many of them have not realised this and are still buying high-end arrays because they always have done and that is what they are comfortable doing. In reality; Clariion, AMS, FAS, XIV, 3Par and a whole raft of others are going to do the job for most purposes; probably 80-90% of the workloads which run on high-end arrays today, no longer belong there.  

It is in this mid-range sector that we are seeing most main-stream development and some of the major new features such as automated tiering and thin provisioning have come from there. It is a very busy sector however and as Chris points out in his blog entry, if integrated stacks become pervasive there are going to be casualties and some of the casualties could be large. 

But there is another emerging market; that is bulk commodity storage; 'Cloud Storage' if you will and I'm not expecting this to delivered as part of the integrated stack for some time. My reasoning for it not being delivered as part of the integrated stack is that it is not yet well enough defined as a concept. Customers are not really ready for it, delivering it as part of the stack adds very little value to the stack at present.

Arguably much of the data which sits on mid-range storage could probably shift down to bulk commodity storage but I think that there needs to be more clarity around the delivery model for bulk storage and how it will/should be integrated. 

So there is a window of opportunity for vendors to innovate in this space but will the traditional vendors seize it? Or will they simply see 'Cloud Storage' as simply another gateway into their current cash-cow? Or perhaps paint the cow a different colour and call it something else? 

I think we've seen evidence of all of these approaches from the traditional storage vendors and maybe their history prevents them from seeing that the delivery model of their product needs to change. 

In fact, this emerging market is being ignored by a great number of these traditional vendors who are hypnotised by the current array market which as Chris points out is about to become a killing field. There are going to be casualties....move to somewhere where lots of people are not trying to shoot each other. The new field is getting crowded but there's still time to stake a claim.

Why, oh why?

After a short hiatus; Barry B is back blogging with a vengeance and I like this entry a lot; there's a lot of truth in it and it does reflect some of my own feelings. And it especially reflects many of my feelings/opinions about vendor blogs; I find vendor blogs a lot more interesting when they are blogging about the 'why' of a product as opposed to the 'what' of a product. 

The best blog entries barely mention a product, you know that there must be a product or at least there is a product coming but that's not really important. It's this discussion of 'why' which should really fuel the debate about the future of IT and data-storage. 

Too much time is spent creating answers to questions which don't exist; time and time again you see kit sitting idle in data-centre because it was bought to answer a question which really wasn't there or at least shouldn't have been asked. 

Here are some of them;

Sometimes, the answer to a question which used to be asked but is no longer. If you dig, this is the 'well, we always do it like that' without realising that actually your customer does not want to do it like that anymore.

Sometimes, the answer to 'what are we going to with the Capex budget which we have left at the end of the financial?'

Sometimes, it's the answer to 'How do I hit my end of quarter/year target?' I discount the crap out of everything and offer a special too-good-to-be-true deal.

Sometimes, it's the answer to question which goes, 'We need to buy something but we've not really spent any time thinking about it...'

And of course, it's the answer to 'What happens if we cancel this project?'

But idle kit should almost never be answer to these questions; if as customer, you don't need the kit pretty much immediately (immediately varies somewhat), you shouldn't by buying it. IT kit depreciates too fast in value to have it sitting idle or even worse, turned on and doing nothing. And even in the case of the canceled project; it is unusual today, that a project requirement is so specific that it's infrastructure cannot be re-deployed.

I like listening to vendors talk about the 'why?' but we as customers should also be talking about the 'why' and why the answers we get from our vendors are right or wrong. 

No Longer Functional

Having worked in Corporate Infrastructure for many years, fighting the good fight and trying to get the enemy to conform to best practise and generally think beyond the next line of code that they are writing, I surrender! I throw the towel in!

I'd like to take an example without being too specific from my own experience; currently in the race to innovate, many corners are cut. Every screen whether it is a TV screen or the screen on a hand-held games device is now potential target for a product. 

Our developers build proof-of-concept systems on servers under their desks at best and often on desktops which might be laying around spare; proof-of-concepts are demonstrated and then proof-of-concepts are products. Cycle times for delivery of new product are often measured in weeks, not the months and years of the past. 

No thought is made to non-functional requirements, the capability is all and it's now a product with paying customers who expect it to be up and running. In fact, the mention of non-functional requirements are enough to send customers running for the hills, they don't want to know. 

But of course, in reality we have to retro-engineer in all those requirements that are required to make it a supportable service. And whilst we are doing this, our people are in a constant struggle to keep this system up. At times, our people do remarkable things in this battle and they should be commended for doing so. 

But there must be a better way than PCs under desks and developers acting like MacGyver to get a new service together? I think there is, I think it's a dynamic, scalable, on-demand infrastructure; call it Cloud, call it what you will. Users should be given the ability to throw-up an environment quickly and easily with almost no thought made to the availability, scalability requirements which will surely be required if the development is a success. 

Yes, some use is made of public Cloud but I think that pales into insignificance when compared to use of commodity hardware which is just lying about; this has been going on since the PC reared it's ugly head but as PC's have become more powerful with the ability to run server operating systems and especially with the rise of Open Source, every developer has the ability to build a 'production environment' without permission. 

Are they doing things in Cloud? Yes, they surely are but I suspect it is a more common situation for a infrastructure team to be presented with a skunk-works system built out of commodity and be told to make it live.....tomorrow. 

And it is then that the Cloud comes into play, it would be much better to have built an environment which allows developers the flexibility and agility that they require, having them work in an environment which can be promoted to a production environment rapidly. An environment which is as cheap and as flexible as the development teams believe that their PCs are but gives the infrastructure teams the supportability that they require.

Non-functional requirements whether we like it or not are just bolt-ons; after-thoughts. They are seen as the obstacles which stop customers gettting the new services which they require, it's time to move on. I still believe that developers should pay attention to non-functional requirements, I still believe that systems should be designed with availability, scalability, recoverability etc in mind but I think that this is now needs to provided in such a way that it is transparent to all.

Of course this transparency should be completely transparent and open allowing rapid migration between providers, private and public...but that is another story!

One door closes, another opens

I find the announcements of the past few weeks from EMC and NetApp around their cloud storage offerings really interesting; it shows an interesting contrast at the moment in approach. One increasingly controlling and one lessening control. 

EMC finally announced a software appliance version of Atmos allowing you to use Atmos with any storage which is certified with VMWare; this is a long overdue move, it's been pretty much an open secret that a software version of Atmos has been existence since prior to launch. It is a software product.

And NetApp announced the repackaged Bycast StorageGrid product; a software product which supported a number of third party storage devices but now only supports NetApp storage. 

As I look at storage and the provision of storage in my working life, I am finding more and more features moving up the stack into the software layer, storage infrastructure is becoming more and more hardware agnostic. More and more the value-add sits above the storage array controller; I can buy pretty much any array and stick it behind a software layer which gives me all the features that I require. 

Beyond the basic provision of RAID, the value of the array in such an infrastructure is pretty minimal and with object stores, even the value of RAID must be questionable. Yes, I can use third party storage with the StorageGrid product but I need to now put it behind a vSeries; this seems to add an unnecessary layer. EMC's move of using a hypervisor layer to ensure that they are dealing with a known environment feels much more sensible in this case.

Yes in generalised block-level; NetApp, IBM and HDS really currently are streets ahead in virtualising third party storage but if EMC start to make even more use of hypervisor layer; they could make real strides in this. Certainly in the mid-range, less performance sensitive space; this approach may just be good enough. 

So I really struggle to see the logic in the NetApp move; mass object storage is about commoditisation and moving features to a more independent layer. And it's also kind of wierd to be in the position where EMC actually give you more choice about your back-end storage than NetApp; it is simply wrong! *shudder*

It's also pretty cool to be able to pretty much build a complete virtual data-centre on my desktop PC using virtual appliances and software layers of various flavours; pity none of them are NetApp's at the moment as they are simply too limited. 

And Barry W, if you read this; pull your finger out and get a virtual SVC appliance available; how hard can it be??

p.s Hah, how many people read the title and thought....another blogger going to join EMC!? 

 

They know Jack....

After latest 'twit-piss' mostly between NetApp and EMC, although HP also chimed in, I posted a tweet which most people seemed to agree with and it got retweeted a lot.

'Let me summarize NTAP know shit about EMC who know shit about IBM who know shit about HDS who know shit about HP who know shit about Oracle!'

But sadly, I don't think it's true at all! I think really goes something along the lines of

'NTAP pretend to know shit about EMC who pretend to know shit about IBM who pretend to know shit about HDS who pretend to know....'

Well you get the gist of it. 

Or perhaps

'NTAP marketing know shit about EMC, whose marketing know about IBM whose...'

Well you get the gist again!

You see there's a big game going on here and actually it's not doing us the customer any particular favours; you see most of the big vendors know alot about their competitors kit, they just can't admit it. I, suspect like most of my readers, have visited large vendor facilities and have been given the full on guided tour; often on these tours, one is taken to the interoperability lab. What's in in the interoperability lab? Well, just about every flavour of competitive kit going. All in the name of testing interoperability but are you really telling me that more doesn't go on? Are you really telling me that performance tests are not run? Are you telling me that the kit is not put through the same type of torture tests that their own kit is put through and that the results are not pored over? 

Frankly I don't believe it! So why don't we get to see the results? Funny isn't it!? 

Perhaps it's just a Mutually Assured Disinformation pact!?

NetApp StorageGrid - More Questions than Answers?

Okay, so NetApp have announced the NetApp StorageGrid product, however at the moment as far as I can see it is a simple rebrand of the ByCast product. I am not sure whether I was expecting anything more or whether I was expecting them to go dark with the Bycast product set for the time being whilst they work out what the hell they are going to do with it and at least come up with an integration strategy for the products.

Like many I wonder what this does to the whole Unified Storage message because NetApp now have two disparate storage product sets which are not integrated; I'm sure that they are briefing the integration message under NDA and if not, I'd ask why? But I'd interested to see what form the integration takes, will be it be at the tools level or will be it more fundamental integration more akin to OnTap 8. 

As NetApp have announced it under the Storage Management Software product set, it appears to be the former, certainly for the short to medium term and I suspect that NetApp are going to be very wary about going after a full blown integration or at least a public statement on it after the torturous integration of Spinnaker.

The data-sheet shows a software gateway layer sitting above the OnTap filers, well I think that's what it shows. It says that the front-end app server supports NFS/CIFS/HTTP(Restful) protocols communicating with the back-end storage via NFSv3; so theoretically, the back-end storage could be anything supporting NFSv3? But at present the data sheet actually shows a very restricted storage environment supported, namely FAS31x0 and FAS20xx and only SATA drives, so there seems to be no way of utilising your legacy storage in your StorageGrid. This is a little disappointing but no huge surprise, if EMC decide to 'support' third party storage with Atmos, it should be no biggie for NetApp to follow suit with StorageGrid; or perhaps vice-versa.

And as ByCast StorageGrid was resold by a number of other vendors, what is the ongoing roadmap for those customers who are running StorageGrid with different vendors storage behind it? Are these customer's going to be expected to move to NetApp storage?

Also from the diagram in the data-sheet;

'NetApp StorageGRID object-based storage solution brings the best of NAS and RESTful HTTP client access together'

Now I am willing accept that NetApp claim that the Filer product set are the best of NAS but to provide this 'best of breed functionality' with the StorageGrid product would imply a deeper level of integration than I can currently see or are they claiming that the Bycast product was actually the best NAS product out there? 

Is the Filer behind the Gateway being treated as pretty a dumb-share-only Filer and not leveraging any of the OnTap features at all? Even if this is the case, it is a cute move politically as the sales-team will not see any potential Filer sales being cannibalised by this new product. A problem that I believe that EMC might have had to deal with the Atmos product set.

One of the keys will be how NetApp present the integration; will they add StorageGrid to Ops Manager? It seems to make sense that you add it at that level because Ops Manager is the preferred way of managing multiple Filers and to get the most out of StorageGrid, there will be many Filers.It also keeps it in the realms of the familiar.

If it is seen as very much a different product it makes the Unified Storage pitch a little harder as it becomes mostly-Unified-Storage product which is a bit like being a little bit unique.

So this announcement asks many more questions than it answers! 

And one final comment, what is the difference between an Storage Grid and a Storage Cloud? Is it an Object Cloud or an Object Grid? Does the Object Cloud live in the Storage Grid??