Storagebod's Blog

Has HP Got the 'X Factor'?

I had a meeting with HP whilst I was out at SNW where we discussed their storage strategy, or rather I gave opinions on their storage strategy. I hope that they weren't expecting anything different! 

Of course, I had to ask the question which everyone keeps asking; now that you've got 3PAR, what is the future of the EVA. I must admit I find HP's answer just a little amusing; 'We'll let the customer decide!' 

What!? Are they going to stage a phone-in? Phone this number to vote for EVA, phone this number to vote for 3PAR? It seems a little mad to me, you don't overpay for a company and then say, we'll let the customer decide whether it has a future or not. 3PAR for Cloud/Service Providers and EVA for mid-range? It is this kind of wooly thinking that has left HP with storage strategy with more in common with a 'Fighting Fantasy' novel than a strategy. 

HP get off the fence and start making some decisions quickly; stop piddling about and give yourselves half a chance in the market.

1) Ibrix or Polyserve
2) 3PAR or EVA
3) 3PAR or Hitachi

Personally, I'd do something along the lines of concentrating on scaling the 3PAR range both up and down for block. And then concentrate on Ibrix for file. At that point, HP have a storage strategy and not the storage equivalent of 'X Factor'. I might be tempted to keep Lefthand around for the time being but I'd look at how much of that functionality I can move into the 3PAR range.

Start working with your EVA customers to plan a migration into 3PAR technology; make it a slick-packaged offering. Plenty of your competitors are putting together migration proposals to their technology from EVA; time for you to do the same.

And if you really want to run an 'X Factor' type competition; Farley and Zito can go toe-to-toe!

 

Please SNIA but don't Sneer!

I met with SNIA whilst at SNW and had an interesting discussion about SNIA in Europe and potential for future directions. But before I get into that; a couple of people mentioned that they prefer SNW Europe to SNW USA on the grounds that the attendance in Europe is more real and that there are more end-users as opposed to a bunch of industry insiders, an interesting observation.

Still back to SNIA; I'm hoping that all my readers are at least vaguely familiar with SNIA, although I have horrible suspicion that many aren't. And I think that is the main problem with SNIA; for example, the attendance at SNW Europe was 1764 delegates which is a record attendance; yet compare that to some of the larger industry events and it's a pretty poor. I wonder why this is? In theory, the audience for SNW should be as large if not larger than those events focused on a single technology. 

For some reason, SNIA appear to be struggling to find a real role in what is still a huge growth IT area; take the SNIA certifications. How many people are aware that SNIA offer vendor-neutral certifications? How many people would even look for them on a CV (Resume)? I'm certainly aware of their existence but it has ever occured to me to look for it when I'm recruiting? Nope, never! 

However, a vendor-neutral certification should be pretty important when looking for designers, architects etc; it should show that the person can think beyond what their most recent vendor told them. I gather that it has more value and recognition in the US but in the UK? It's really a non-factor; I wonder whether it would be possible to turn the SNIA certifications which have a level of recognition akin to that of the CISSP? That's one of the challenges that I think SNIA need to take on.

End-user engagement; getting end-users involved somehow in their standard's initiatives might bring a healthy dose of reality to them. But we are all busy people and getting time away from the day job to do this sort of work is hard but maybe SNIA can engage with a good social media strategy; Twitter, Blogs (their own but also commenting and engaging in debate on the existing blogs), turning up to #storagebeers and generally getting more visibility. 

Fortunately, SNIA seem to understand all this and certainly have ambitions to do many of these things; let's all of us encourage them! Face it without the end-users, there is no Storage Networking Industry and hence no need for an Association. I think that we need to be telling these guys what we want to ensure that they stay relevant to us.

Go to the Academy events; if you don't get anything of value from them, collar the organisers and explain (politely) what would make them better. Go to SNW if you can and do the same. And the SNIA guys, come along to #storagebeers; if you aren't engaging with the sort of people who attend #storagebeers, you are missing out on a whole bunch of end-user enthusiasts who could do you a lot of good. 

Cryptic Conundrum

At SNW Europe this week, Emulex announced it's host based storage encryption using Emulex OneSecure adapters or the Lightpulse 8 gig adapters. This approach protects data in flight and also data at rest. The press conference was interesting and the wheels' pretty much came off for a variety of reasons.

1) Using a spurious example of a security breach which wouldn't have been prevented by their technology. 

2) Ignoring the social media back-channel despite the attempts of their PR to draw attention to it.

3) Trying to present 20 slides in 30 minutes (and failing)

4) Not planning for the possible objections; for example, their approach would completely negate the value of primary storage compression/deduplication. In fact the presenters seemed to be pretty much unaware of primary stotage deduplication. I didn't even mention NetApp's PAM technology and it's VDI use-case.

Anyway, as press conferences go (and I've not attended many), it was a bit of a fail but it did lead to some interesting conversations afterwards and led me to think about storage encryption in general and how people implement it. And also how future technologies could impact it's value if people are casual about their implementation.

Where is the right place to encrypt? Emulex's approach of encrypting at the host and then storing the encrypted data on the array is certainly a valid approach; it means that the array doesn't need to do anything to encrypt the data and it becomes completely storage agnostic. But, as Emulex are touting this as a HBA based solution with an offload engine on the card; this means unless the approach is standardised and accepted across all HBA vendors, you will become tied to Emulex to provide your HBAs. 

Good for Emulex, maybe not so good for you. If your server vendor falls out or decides not to certify Emulex cards in their servers, you are going to be look at changing your server vendor as a result or go through a lengthy and expensive migration. 

Also Emulex's approach completely ignores the local storage as far as I can see; many people still have their operating systems stored on local disk, we can argue whether people need to move to boot off SAN but reality is reality. In fact, I wonder how many people are implementing disk encryption technologies on their SAN and simply ignoring the local disk; well, the local disk only contains the operating system and that's not important to encrypt!

Well think again, what if you've paging files on the local disk? What about memory dumps? Lots of interesting information could be extracted from this. And if you think you'd need to be some kind of hacker genius to extract this information from those files; it is probably easier to extract useful information from these files than it is to extract useful information from a single disk from taken from an array which is raided, striped, deduped, compressed and block-level autotiered. 

Then if we throw in the idea of flash-based server caches like Fusion-IO; I'm sure one of those could reveal all kinds of interesting information. And if you demand that a failed Fusion-IO card is shredded; the costs are going to end up being astronomical.

And then, Emulex's approach only supports block-based I/O; what about the increasing NAS estate where all kinds of seriously confidential files are stored? Or the growing number of virtual machines stored on NFS.

Encryption of data is important and we may need several different technologies/techniques to address the issue; scalable key-management is going to be challenging and certainly when we have automated technologies moving data in and out of different storage technologies; indeed, these technologies could be moving entire instances around.

In all honesty, I think Emulex's approach when you start to think about it is one of limited appeal. How do I encrypt and protect sensitive data is certainly a question we get asked; I'm not sure we've got really good answers quite yet. 

Briefing Bloggers - Some Thoughts!

Talking to some of the PR bods at SNW Europe was enlightening and especially the fact their customers find it incredibly hard to know how to deal with the independent bloggers. In fact, some of them actually seem to be scared of us and would probably rather that we went away. So as one of these scary, random and opinionated independent bloggers; I thought I’d reflect on how I think you should interact with us or at least with me.

Now, I have no pretensions to being a journalist, a hack or any other kind of professional writer; I do this for pure fun and my own interest, a gentleman amateur may be? So for example, take SNW this week; although SNW picked up the bill for the hotel, flights and much of my sustenance; I was not paid and indeed I took leave from my day job to attend. Chris Evans who was also attending with me is self-employed and the days he spent at SNW were days when he wasn’t earning fees. 

So first thing; you are interacting with ‘Martin Glassborow, blogger’ not with ‘Martin Glassborow, an employee of a large media company’; this is not your chance to try and sell to me in this role. Now obviously my day job does give you some context as to what I do and what my experience is but if you want to try to sell to me as a corporate employee, you would be better trying to book a meeting with me when I am on the clock. You can try to frame your product in a term of reference that you might think is relevant to me but to be honest, you’ll probably get it wrong. 

Funnily enough, if you are trying to use my status as a blogger to try to influence my employer’s buying decisions; you are very misguided. I have little influence on those decisions but I do have influence on what my readers look at and consider. Admittedly my influence is probably quite low but I do have a fairly wide readership and for some strange reason, people seem to listen.

And may be that’s because I don’t just write about this stuff, I use this stuff; I think this is the core difference between the bloggers and most journalists. We have the scars from actually using products and these scars aren’t from paper-cuts. We can be a lot more critical and confrontational if you pitch something which is plainly stupid, wrong or just won’t work in our opinion. We are the poor suckers who might end having to make it work; we don’t simply move onto the next story. It’s not personal but we deal in reality, not press releases. 

Yet even that statement is not really true, if you want to find out what the latest speeds, feeds and features of the latest products, I don’t really do that. My blog is my soap-box, it is full of opinion, conjecture and speculation; I write about my reality, not the alternative reality which is vendor wonderland. But my reality is certainly not everyone else’s. 

When pitching to me as a blogger, remember that this is going to be a conversation and I will be expressing opinions; if you get this interaction right, you might well learn as much from me as I do from you. Certainly defend your position but don’t get defensive! By the way, most of the storage bloggers tend to be pretty smart guys and if they don’t get your product; you are probably pitching it wrong or you’ve just had an ‘ugly baby moment’! 

I will often bring up rival offerings from your competitors; I’d prefer it if you didn’t look blank, didn’t just simply dismiss it as inferior or generally try to position your product as somehow unique. There are very few unique ideas about and many of those products which are in some way ‘unique’, there may well be a reason why this is the case. 

As a blogger, I like to put things in context and not just as a product; for me, often the why is more important than the how. I want to know the question for which you believe your product is the answer. If I can’t see the question, I’m probably not going to blog on your product.

Anyway, just some thoughts which will probably develop on how to deal with this tribe of irritants which will hopefully grow; the independent blogger…or as EMC like to call them, Chad’s Reserves!

 

SNWE #storagebeers

There will be #storagebeers at SNW Europe this coming week and for once, I'll be in attendance for beers outside of the UK. 

These will at the Champions Bar at the Marriott opposite the Congress Centre where SNW Europe is taking place in Frankfurt starting from about 7:30 on Monday 26th and Tuesday 27th October. I'm looking forward to meeting as many of you as possible either at #storagebeers or at the actual event. 

I should thank the team at SNW Europe for making my attendance at the event possible as they are picking up my flights and my hotel bill. 

We are also talking about arranging UK #storagebeers to celebrate the festive season later in the year; keep a look-out here and on twitter for news on these. 

And next year, we hope to do rather more with #storagebeers and perhaps do some more 'formal events'.

EMC's next acquisition?

So are EMC are rumoured to be interested in Isilon; twelve months ago I might have dismissed that out of hand but now I'm not so sure and I think it makes sense for a couple of reasons. 

1) Isilon are strong in the media space; EMC aren't. Now, let's not kid ourselves that the media market is huge compared to the traditional enterprise market but it's certainly large and growing though. And many media houses are now making the move to file-based workflows away from video-tape; the storage requirement here is pretty massive and EMC arguably don't have a product which fits especially well. Atmos could fit but the application integration is not there yet and actually, much of Atmos' functionality is replicated at application layer in many Media Asset Managers. 

Media also has an air of cool about it; I'm sure Chuck would love to blog on how EMC storage was used to render the latest Hollywood blockbluster, it's a great marketing opportunity. It's all very well to point to a VMAX which is in the background of a film but I reckon he'd be even happier if he could tell the world how EMC storage was actually used to make the film as opposed to an expensive prop/extra.

2) Cloud and Virtualisation; if NFS is going to be the protocol choice for VMware and hence much of EMC's interpretation of cloud, Isilon could be a really useful asset for them. A massively scalable NFS environment which can grow both capacity and performance independently without outage, without moving data between storage devices keeping all that data movement off your network/SAN; that is a really powerful enabler for the virtual data-centre. 

Isilon are going pretty well in VMware environments, quietly growing their footprint and this EMC's chance to pick up a company which could hurt both them and NetApp. It's funny to think that a company that EMC own actually enables the competitors to tell a stronger story about their products. This is EMC's chance to nip this in the bud with Isilon and although I think the figures being talked about for Isilon are pretty high; in five years time, it could turn out to be a relative snip.

It's funny that Dell are discussed as a rival bidder for Isilon; I'm surprised that other partner isn't. Isilon would be a very interesting fit for Cisco if they decided that they actually wanted to own yet more of the virtual Data Centre. 

I think that Isilon's days as an independent company are numbered, despite all their protestations that they intend to stay independent and do what to NetApp what NetApp to EMC...I mean I heard exactly the same sort of comments coming out of 3Par and look what happened there?

 

Sound of One Node Clustered

I've got a quick and dirty implementation to do at work but like all quick and dirty pieces of work; you know that the decisions you make in haste will come back and haunt you if you don't do them right. Luckily, we have some idea what the end goal should be and are trying to put together the path which will get us to that end goal without causing us too much trouble but the user is impatient to have something, so we've got to give them something.

In this case, this means us potentially building a single node cluster; we could do what the user requires now without a cluster but it will be harder in a couple of months to retrofit the final solution in as opposed to simply expanding the cluster. Building a single node cluster in this case is not hard and really only requires us to ask for an extra set of IP addresses and installing the cluster software.
And this led me to scratching my head again!

Why on earth did NetApp create a non-cluster mode for OnTap 8; this is just storing pain for users at some point going forward? A well written cluster mode has so many advantages, it seems like madness not to encourage users to go for it and it's actually a very clever potential lock-in for NetApp.

Not only that, currently, it is pretty much as painful to go from OnTap 8 7-Mode to OnTap 8 Cluster-Mode as it is to refresh your NAS device with another vendor's kit. Personally, the more I think about it; the more I think that NetApp have missed a trick on this. I am absolutely convinced that they actually over-reached themselves on OnTap 8 and promised the earth; realistically they've under-delivered. 

Most users probably won't notice this under-delivery but NetApp could have made our lives a lot easier. A single install mode which was automatically ready to be clustered was what was wanted; seamless addition of heads and seamless migration between heads. This was an opportunity to not simply delight customers by meeting their needs today but also their needs in eighteen months time when they need to add more capacity. How much simpler would it be to simply add in another head with some additional capacity and have it available for the whole namespace without have to create another one?  For all NetApp's vaunted embracing of the cloud; this seems to be a missed opportunity. 

Starting small and growing incrementally does not really seem the order of the day for NetApp; hoping that they can do better in the next releases. But if they don't, there are an ever growing number of clustered NAS devices waiting in the wings which although on the face of it offer very little over the traditional NAS devices from NetApp (and EMC) but long-term if I was a service provider looking for a long-term strategy which does take account of growth and technical refresh, I would be tempted to be having a long hard look at.

Of course, one can't really call OnTap 8, quick and dirty... 

It Cuts Both Ways

You can't have it both ways and it appears that some in IBM want to have it both ways. IBM historically have enjoyed benchmarketing and have historically kicked EMC for not submitting Symmetrix for SPC. EMC have responded that customers don't run SPC as a workload and it does not realistically reflect a true customer workload. At which point the whole storage industry blows a raspberry and calls them chicken.

But read this comment from StorageBuddhist on my blog entry 'Wither XIV'

"The closest you will get to an XIV benchmark is probably my blog post from April http://storagebuddhist.wordpress.com/2010/04/06/xiv-ms-exch-2007-replicated-performance/ but being a non-trad box, XIV has a very non-trad performance profile. We recently heard from a customer who has got more than 100,000 IOPs out of their XIV in the course of normal business duties - something I had previously assumed was only possible in the labs." 

I'm trying to work out what he is saying; is he saying that XIV is only suited for non-traditional workloads?  Why won't IBM publish standardised benchmarks for XIV, they do for everything else they ship? If they could find a way of benchmarking the free pens they hand out, they would! I know he doesn't mention SPC but that's the standard benchmark for storage that IBM support.

You can't call EMC out for not submitting their arrays to SPC and then not submit one of your own because you know it will perform poorly.

Either SPC is a valid storage benchmark or it's not! Or perhaps XIV is only good for running some workloads? You see if that is the case then no matter how simple it is to manage; it does mean that to cover all my workloads, I am going to need multiple types of array and that builds in complexity to the environment. And at that point, does not much of XIV's selling point go down the toilet? I will still need a traditional storage team to tune and manage those applications which need a traditional array to perform and don't only perform well when run from cache. 

Do I think EMC should submit their arrays to SPC; actually, I do. Do I think IBM should submit all their arrays to SPC and not cherry-pick which they do, abso-blooming-lutely I do. Or IBM should come very clean as to what applications those arrays they do not submit to SPC are not suited for. If they do not, they call the whole validity of the SPC into question.  

Wither XIV?

So IBM has a new mid-range array in the form of the Storwize v7000; the question is did it need one and what happens to the rest of the range? In the midrange space, IBM now have two of their own arrays in the form of XIV and the v7000; they also have the DS5k which is OEMed from LSI. 

IBM beginning to disengage from their storage OEM partners was eminently predictable; IBM have finally woken up to the fact that they need to own the stack and partnering was not going to allow them to steer their course in the coming 'Stack Wars'. However, the DS5k probably does have a part to place at least in the short term in some niches; the EXP5060 high-density enclosure certainly has a part to play in this.

XIV, though, is looking vulnerable and not for the reasons that I think some people expect me to state. XIV, simply does not make sense for IBM economically; it costs too much to make I suspect. But 'Bod, XIV is made from commodity components; it should be as cheap as chips to make.

Yes, XIV is made from commodity components but it's made from an awful of them to build an array; the v7000 is also made from basically commodity components in a custom form-factor and it uses a lot less of them to deliver better performance and more capacity. The Bill of Materials for an XIV is going to be significantly higher than for the v7000; this makes v7000 more profitable to IBM and/or will allow them to discount the v7000 more substantially. 

The latter is going to be hard with the current XIV set-up which pretty much runs with their own sales-force; IBM will find themselves competing with themselves but I am sure that they will be happy to accept the higher margins that the v7000 could deliver. 

Of course, there are some savvy customers out there who are going to do the same sums as me and are going to ask some hard questions; if you can supply XIV for 'x', why do I have pay 'y' for v7000 when it costs you less to build and supply the v7000.

Now, I know there are some readers who are going to mention that XIV is rumoured to be delivering some much awaited improvements such as improved inter-node connectivity and clustering; I've also heard that something along the lines of NetApp's PAM may also be delivered.  You could stick an XIV full of SAS drives which would improve performance but increase cost; you could build an XIV based around 2.5" drives which might have been an interesting proposition, improving performance and capacity. But none of these is going make XIV any cheaper to make and any more an attractive option for IBM.

XIV's killer feature is it's ease of use and self-tuning capability but are users willing to pay a premium for this to enable the range to continue to be economic for IBM to make? Could IBM actually position the XIV as the AS400 of storage; the box you stick in the corner and forget about? I guess, that's possible but storage is a phenomenally price competitive market despite the attempts of people to pretend it isn't. 

And the v7000 does not look exactly hard to use and configure; I'm also sure that IBM have learnt lessons about self-tuning systems from the XIV which can be applied more economically to it's more conventionally architected storage systems. I expect IBM to keep XIV around for at least another generation; it's an insurance policy at least but I'm not sure it's got a long term future in it's current form.

XIV could find a new lease of life though as a combined compute/storage appliance; that might make a lot more sense. Perhaps as a grid-based deduplication device? Or it might simply go down in history as this storage generation's Iceberg? An array full of interesting ideas which never quite fulfilled it's potential and in ten years from now; we'll be say remember the XIV, it had that feature first. 

But ultimately, it won't be the users who will kill the XIV as a storage array; it's IBM themselves, it just doesn't make sense.

Manage Data Not Storage

With Automated Tiering solutions now rapidly becoming de rigeur, well in announcement form anyway; perhaps it's time for us to consider again what is going to go wrong and how much trouble the whole thing is going to cause some people. 

Fully Automated Tiering solutions are going to cause catastrophic failures when they are deployed without understanding the potential pitfalls. I keep going on about this because I think that some people are sleep-walking into a false nirvana where they no longer need skilled people to manage their infrastructure estates; in fact, automated solutions means that you are going need even more skilled people; you will probably need less monkeys but you are going to need people who can think and learn.

Fully Automated Tiering solutions cannot be fully automated and be safe for most large businesses to run; they work on the premise that data gets aged out to slower and less performant disk, this reduces the amount of expensive fast disk that you require and can save you serious money. So why wouldn't you do this, it's obvious that you want to do this, isn't it? 

Actually in most cases, it probably is; unstructured file data almost certainly is safe to shift on this basis, actually most unstructured data could be stuck on the lowest tier of disk from day one and most people wouldn't notice. In fact you could write most of it to /dev/null and not that many people would notice. 

But structured data often has more complex life-cycle; accounting and billing systems for instance, the data can be very active initially eventually entering a period of dormancy when it basically goes to sleep. However, then something will happen to wake it up; periodic accounting runs, auditing and then the data will be awake and almost certainly required pretty sharpish. If your automated array has moved all the dormant data to a less performant tier; your periodic accounting jobs will suddenly take a lot longer than expect and potentially cripple your infrastructure. And that is just the predictable periodic jobs.

Automated Tiering solutions also encourage poor data management policies; actually, they don't encourage but they certainly reinforce a lot of bad practise which is in place at the moment. How many people have applications which have data which will grow forever? Those applications which have been designed to acquire data but do not age it out? Well, with Automated Tiering solutions, growing your data forever no longer attracts the cost that it once did; well, certainly from a storage point of view and it might even make you look good; as the data continues to grow, the amount of active data as a percentage of the estate will fall and hence the amount of data which sits on the lower tiers increases and you could argue that you have really good storage management policies in place. And you do!

However, you have really poor Data Management policies in place and I think that one of the consequences of Automated Tiering, is the need for Data Management; your storage might well be self-managing, your data isn't. If you do not address this and do not get a true understanding of your data, its life-cycle, its value; you are looking down the barrel of a gun. Eventually, you are going to face a problem which dwarfs the current storage-management problems.

What kind of problems?

• Applications that are impossible to upgrade because the time taken to upgrade data-in-place will be unacceptable.
• Applications that are impossible to recover in a timely fashion.
• Application data which is impossible to migrate.
• Data corruptions which down your application for weeks

And I'm sure there are a lot more. It's hard enough to get the business to agree on retention periods for back-ups; you need to start addressing Data Management now with both your Business and your Application teams.

The good news is that as Storage Management becomes easier, you've got more time to think about it; the bad news is you should have been doing something about it already.