gestaltit

Much of what we do in Storage Management can be considered living on a prayer; this is not just a result of the parlous state of the storage management tools that we use but also due to the complex interactions which can happen within shared infrastructure.

And frighteningly enough, we are in the process of making the whole thing worse! The two darling storage technologies of the moment; thin provisioning and de-dupe scare me witless. Both of these technologies in the wrong hands have the capability to bring a server estate to its knees. By wrong hands, I mean just about anybody.

Both of them allow you to virtualise capacity and allocate storage which isn't actually there and hope that you never need it.

Thin provisioning is predicated on the inefficient practises that we have come to know and love; we all know that when a user asks for storage, they nearly always ask for too much! Thin provisioning allows us to logically allocate the disk and only when it gets written to, does it actually get consumed.

The problem is, what happens in the event of a perfect storm and every application wants its capacity at the same time? How much do you over commit your physical capacity? Or maybe not a perfect storm, you just realise that you're going to add physical capacity above and beyond that which is supported by the array simply to cater for rate the thinnly provisioned storage is being consumed.  A rapid application migration ensues.

And then there is the scarey proposition of de-duped primary storage. You could be many times over-subscribed with de-duped storage; certainly in a virtualised server environment or a development environment where you have many copies of the same data. And then someone does something; a user decides to turn on encryption and what was many deduped copies of the same data actually becomes many full copies of the same data and you have run out of storage space in a spectacular fashion.

Also migrating deduped primary storage between arrays is going to be a lot of fun as well and is going to need a lot of planning. Deduping primary storage may well be one of the ultimate vendor lock-ins if we are not careful.

Both thin-provisioning and primary storage dedupe take a lot of control away from the storage team; this is not necessarily a bad thing but the storage team now need to understand a lot more about what their users are doing.

It will no longer be enough to just to think about supplying spinning rust which can deliver a certain amount of capacity and performance. We are going to have to understand what the users are doing day-to-day and we are going to have to communicate with each other.

And yes, we'll need better tools which allow us to see what is going on in the environment but also to model the complex interactions and impacts of various events. We are going to need to know if a user is intending to do something like enabling encryption, a big data-refresh, operating system patching; events which in the past were not hugely significant could now have serious ramifications to our storage capacity.

I still think that thin-provisioning and de-dupe are good ideas but like all good ideas; they come with challenges and a certain amount of risk…

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?

Steve Duplessie is both right and wrong in his post on SSDs here!

He is right that simply sticking SSDs into an array and treating them as just Super Speedy Disk can cause yet more work and heartache! Concepts such as Tier 0 are just a nightmare to manage!

He is also right that the problem should be defined high-level as the interaction between the user and their data, getting them access to the data as quickly as possible.

He is also right that just fixing one part of the infrastructure and making one part faster does not fix the whole problem. It just moves the problem around!

Unfortunately, whilst every other component in the infrastructure has got faster and faster; arguably, storage is actually getting slower! At a SNIA Academy event recently, they suggested that if storage speeds had kept up with the rest of the infrastructure improvements; disks would now spin at 192,000 RPM. The ratio of capacity to IOPs gets less and less favourable every year; wide striping has helped mitigate the issue but as disks get bigger, we either look at the situation where we waste more and more capacity as the areal density of IOPs means that most of the capacity on a spindle should just be used for data at rest or we need a faster storage medium.

But we probably don't need a huge amount of faster storage medium and a small sprinkling will go a long way; that's why we need dynamic optimisation tools which move hot chunks of data about. SSDs will be good but just treating them as old-fashioned LUNs might not be the best use of them.

Automation is the answer but I think Steve knows that! Dynamic optimisation of infrastructure end-to-end is the Holy Grail; we are some way off that I suspect! I'd just settle for reliable and efficient automation tools for Storage Management at this point. 

Whilst HDS and EMC throw rocks at each other with regards to whether it is better to build custom parts or take things off the shelf and just use custom when you require (I'm expect the other Barry to sit on his hands but there are good reasons why the SVC team decided to build out of commodity parts and I suspect that they are very similar reasons to EMCs). I think we should look beyond the hardware and look at what is coming down the line to us.

The most important thing roadmapped is FAST, Fully Automated Storage Tiering. FAST changes things; it takes a whole bunch of ideas from a whole bunch of places and runs with them. If you are another vendor and you feel aggrieved that EMC have stolen your idea; just take heart, it won't be the first time in history that this has happened and it won't be the last.

The foundation is Wide-Striping* using a model which splits your data into chunk(let)s and spreads it across spindles. Once these chunks are distributed, you can monitor the characteristics of the I/O at an individual chunk level; this allows us to do tiering at a sub-LUN level. A hot chunk of data can be moved to a higher tier and a cooler chunk of data down into a lower tier.

In the past we have been limited to moving a whole LUN (with the exception of Compellant); this has always been a time consuming job, identifying what needs to move and then moving it. Yes, technologies have come along to make this easier but to sweat the asset and especially to make best use of SSDs; we needed to move individual 'blocks' as in a given file-system , it is possible that only some blocks are hot and frequently accessed. Traditionally if you could, you would hold these in cache but if SSDs are expensive, cache is yet more so. This approach will allow some cache to be replaced by SSDs and for some cache unfriendly workloads, to all intents and purposes, you have massively increased the amount of cache available. You might not want to hold a terabyte or so of real cache for that evil 100% random read app but with SSDs; this becomes viable and not at a huge utilisation hit.

But there are going to be issues with the FAST approach; firstly, where do you put a new workload? If you simply assign it some disk and let the array decide, what the hell is it going to do with the workload? It could put it on the slowest tier possible and then migrate up; it could stick it on the fastest tier and migrate down. Both of these approaches have significant risk, so I suspect we are going to have to give the array some clues and we are going to have to understand more about the whole system we are putting in. The difference in performance between the top tier and the bottom tier is going to be large.

No longer will the Storage Admin be a Lun Monkey; they are going to need to really understand their workloads and the applications. They are going to need to learn to talk the application developers and understand workloads, they are also going to have understand business cycles.

For example applications which spend 11 months of the year pretty idle may suddenly at year end need a lot of performance. What happens if all your applications demand stellar performance once a year? Perhaps you need a way of warning the array that it needs to prefetch a load of data. A badly written end-of-year reporting extracting which generates thousands of random read IOPs. A badly written user-generated SQL; in the past, this just crippled the application; with FAST, this could cripple the whole array as it tries to react.

The FAST approach is potentially the thin-provisioning of IOPs. This going to need a lot of thinking about. Potentially you will have to domain storage to protect applications from the impact of one another. We are going to need to know more about the whole system than we have before if we are to truly benefit from FAST,

Building rules which suit your applications; sure, V-MAX will come with its own canned rules for things like VMware and known applications. Indeed EMC will probably be leveraging all the performance data that they have been gathering over the years to help us write the rules. Storage Templates as described by Steve Todd here are just the start.

So although at one level, the Storage Admin's job could get alot easier; the Storage Manager's job has got a whole lot harder. Yes Barry, I asked for FAST and now you've given it to us; now we'll have work out what this all means!

I have some really 'interesting' ideas as to where EMC could take V-MAX but they'll have to wait for another time as I'm still supposed to be on leave from Enterprise IT.

* It's Wide Striping not Wide StripPing as I keep seeing written; Wide Stripping is what happens on a Rugby Tour after a good night out!