This article is more than 1 year old

The LUN must DIE. Are you with me, storage bods?

You want multiple LUNs for our terabyte+ database - are you HIGH?

Storagebod I know people think that storagebods are often backward thinking and hidebound by tradition and there is some truth in that. But the reality is that we can’t afford to carry on like this.

Demands are such that we should grasp anything which makes our lives easier.

However, we need some help with both tools and education. In fact, we could do with some radical thinking as well – some moves which allow us to break with the past. What I am going to suggest almost negates my previous column - but not entirely.

The LUN must die. I cannot tell you how much I loathe the mere existence of the LUN.

Why, you ask?

Because it allows people to carry on asking for stupid things like multiple 9GB LUNs for databases and the likes. When we are dealing with terabyte+ databases, this is plain stupid. It also encourages people to believe that they can do a better job of laying out an array than an automated process.

We need to move to a more service-oriented provisioning model, where we provision capacity and ask for an IOPs and latency profile appropriate to the service provision. Let the computers work it all out.

This significantly eases management and removes what has become a fairly pointless abstraction from the world. It makes it easier to configure replication, data protection, snaps and clones and the like. It means that growing an environment becomes simpler as well.

It would make the block world feel a little closer to the file world. Actually, it may even allow us to wrap a workload into something which feels like an object – a super-big-object, granted, but still an object.

We move to a world where applications can request space programmatically if required.

As we start to move away from an infrastructure which is dominated by the traditional RAID architectures, this makes more sense than the current LUN abstraction.

If I already had one of these forward-looking architectures, say IBM's XIV or HP's 3PAR, I’d look at ways of baking this in now. This should be relatively easy for them – certainly a lot easier than some of the more legacy architectures out there. But even the long-in-the-tooth and tired architectures such as VMAX should be able to be provisioned like that.

And then what we need is vendors to push this as the standard for provisioning… yes, you can still do it the old way but it is slower and may well be weaker in performance terms.

Once you’ve done that, perhaps we can have a serious look at things like Target Driven Zoning. If you want to move to a software defined data centre, enhancements to the existing protocols like this are absolutely key. ®

More about

TIP US OFF

Send us news


Other stories you might like