Application-Aware Storage Archives • Home

There’s a lot of discussion the marketplace today about Thin Provisioning, but before we get into it, let’s set some ground rules on definitions:

Allocation: The logical capacity or size of a LUN.

Provision: The physical reservation of space on disk – to guarantee that space exists and is spoken for.

Now that we have key terms defined, there are essentially two ways to look at Thin Provisioning:

Thin Provisioning in a storage subsystem allows a disparity between capacity allocation and provisioning. In other words, one can allocate 2TB for a LUN, but provision significantly less than that. The details of how much less, how the provisioned storage approaches or grows toward that allocated depends on the design of the system.

Here is the goofy part: To the unfamiliar, the idea that you should be able to increase the size of a LUN on the server using it and the storage system providing it doesn’t seem very sophisticated. In fact it seems kinda dumb. Of course you can do that can’t you? No, not so simply on all operating systems and storage systems.

Also – the idea that just because someone says they want a 2TB LUN that you dedicate all that storage, even if they are only using 200GB of that allocation seems kinda old fashioned (it is). In other words, when you show up at the airport and expect to have a seat on the plane because you own tickets, well, yes, that used to be the way it was; same for a hotel. But now, there is this thing called overbooking…..Airlines and Hotels make sure their seats and rooms are fully utilized by assuming that they can overbook since usually not everyone shows up to claim their seat or their bed. Similarly, not everyone who allocates 2TB for a LUN uses all the space.

So what seems obvious isn’t.  Some operating systems make it very difficult to increase the size of a LUN, and in fact it may require taking the system offline to do so. Of course this is really bad, and people usually over-allocate to prevent ever having to do so. Well, if you over allocate a bit, it’s not too harmful. But people don’t often forecast storage for an application really well. In fact, they have been burned many times under-allocating, so the disparity is often large. People often allocate 2X and 3X what they think they will use. If your storage system reserves that space, the unused space is wasted, plain and simple.

Underutilization is waste. The strange thing for most of us to get over is: the waste is avoidable without Thin Provisioning. But most people don’t want to worry about it, so they waste anyway. A Storage system that doesn’t provision the storage until there is data to fill it up solves this problem to the degree it is a problem. Some Storage Administrators work hard not to allow underutilization, so for them this may be easier, but it doesn’t change the efficiency of their storage system. Instead, Thin Provisioning merely shifts the work from their planning and careful management to software inside the storage system that is flexible. Not a bad thing either.

While Thin Provisioning can be a great function, it does not solve the general utilization problem, because utilization gets compromised by Admins using spindles of a given capacity to build LUNS with certain IOP capability. While they may need 500GB of capacity, they need 2000 IOPS.  Getting 2000 IOPS out of a disk is not going to happen (see Blog on Spindles Count or Count Spindles). With FC disk, you will need about 10-12 disks depending on RAID type, read-write bias, and a few other factors. Building a LUN out of 10-12 disks to support this performance the will waste a TON of space. For 146GB drives, you would waste about 7-9 disks worth of space!

Unless you have Pillar’s QoS. With Pillar’s Axiom, the data gets laid out over the number of spindles you need to get the performance, and the disks are shared amongst other applications in such a way as to parcel out the performance that those applications need. Utilization nearing 100% can be achieved, although that allows no headroom for growth and such so 80% is more advisable.

But can’t other systems share disks to build LUNS? Sure, as long as you don’t mind LUNS interfering with each others’ performance. This is why disks are usually dedicated to applications! Without QoS, interference is bound to happen, and dedicated disks almost always imply underutilization – which has nothing to do with Thin Provisioning.

We have competitors that think that QoS is data placement on disk. Well it’s part of it. Without a prioritized queue manager in front of the disk, copying Pillar’s data placement on the platter and striping over spindles can (and usually does) result in WORSE performance instead of better!  Pillar not only has a prioritized queue manager, but we optimize all the other system resources as well, like cache (which some competitors have shockingly little of because they built their architectures in the days of core memory ☺)

The meat behind Pillar’s claim as the first and only true Application-Aware storage is the combination of technologies such as Thin Provisioning, prioritized queuing and intelligent data layout.  One without the others does not deliver on the promise we’re all driving for.

At Pillar, we have always prided ourselves on innovation. We invented QoS for Storage, and 5 years ago we built our storage administration around application templates. Essentially, when someone wants to set up LUNs for Oracle, Exchange, or SQL for example, they can follow best  practices configurations for any storage array. So, we felt at the time, if one follows best practices, why not just use a pull-down menu selection against standard applications that does all the work for you? Well, this is exactly the approach we took 5 years ago, and started shipping with the Pillar Axiom two and-a-halfyears ago. It was and still is a great idea, avoids re-inventing the wheel every time you layout storage for an application by allowing the admin to fill out the variables, like Capacity, I/O characteristics and such, and avoid having to configure disk drives in arrays like all the old school systems out there.

From our perspective,  application-awareness implies configuration of disk, but in the case of Pillar’s Axiom it also implies things like cache configuration, network bandwidth, CPU priority, and layout of data on the disk platters. In other words, all the system resources are tailored to the application – set up to make the application see the best possible disk attributes out of the resources in the array.

Let’s take an example. Let’s say you want to configure the LUNs for an Oracle 11g database and Oracle Apps. How would you do this? We know that the live database will require good random read and write performance on high performance disk, while archive partitions can use lower performance disk allowing the core database to stay optimally tuned. Finally, the applications themselves can reside as a lower priority than the database but higher than the archive partitions. These are all performance characteristics that the DBA can tell the storage administrator (or the storage administrator already knows). That storage administrator can choose to create profiles within the Axiom for these various workloads, and then simply provision capacity (as shown below); or even better, allow the Oracle DBA to assign capacity, using the newly created profiles, via Pillar’s integration with Oracle Enterprise Manager. And just in case there is a temporary need to improve performance (discovery motion or data mining) for an archive partition, the Axiom allows that administrator to change queuing and cache tuning (relative performance) on the fly, newly empowering that application for the duration of the required performance bump.

What if you change your mind or circumstances in your business change? No problem, Axiom migrates the data on the fly from one disk configuration to another, and unlike any other storage in the marketplace, it also changes CPU priority, queueing priority, cache configuration etc. So with Axiom, today’s choice is not tomorrow’s problem.

Thus, Application-Aware Storage is essentially storage that takes best practices into account and does all the work to configure your array resources to best meet those needs: Pillar’s Axiom does exactly that; automatically and dynamically.

Cool right? I suppose some people would rather write a bin file, or be forced into using RAID 4, but most of us would rather leave that piece of our past in the past.