RSS
Email
Print
ShareDebunking Utilization As Justification
Posted by Howard Marks on October 29, 2009
If I sit through another presentation or sales pitch that tells me how a product will save me money by raising my storage utilization, I'm going to get violent. Ever since the development of the SAN, vendors have been extracting money from users based on promises that their new shared disk array, virtualization widget or storage management application will pay for itself by increasing the customer's disk utilization. For ten years now, we've spent a lot of money but the savings have been elusive.
Basically the myth of savings from improved utilization is based on two false assumptions. The first is that a typical enterprise is using 3-30 times as much raw disk space as they have data, because of limitations on the tools the storage administrators have at hand.
This is the basic "if we put all our data on a single storage array we'll raise utilization" situation: if each server has its own RAID controller and DAS disks there must be at least a disk's worth of free space on each one. By using a single large array, all of that free space can be in a single pool and we can allocate it more efficiently.
The fallacy of this argument can be demonstrated by several studies showing that organizations moving from DAS to shared disk arrays don't typically see huge changes in utilization. Using conventional arrays still builds multiple RAID sets with different service levels, so they don't have the single shared pool they dreamed of. And, of course, they are still over provision.
The other problem with this purchasing argument is that the cost per GB of the new system is sometimes significantly higher than on the old. Adding a 3TB SAS JBOD to a database server would cost around $5/GB from Dell or HP. The same capacity in a EVA, Clarion or similar midrange shared array would cost at least $15/GB once FC connectivity is factored in. At that rate we'd have to use 1/3 as much disk space just to break even. Even worse, I've heard sales pitches where vendors were telling the CIO that higher utilization would create savings over the storage they had already paid for.
Comment by Sammy_Storage on October 30, 2009 1:02 AM
Let's see, Utilization is using a greater percentage of the capacity you bought. So if you actually use a greater percentage of what you allocate then that aspect of utilization goes up. If you allocate a greater percentage of what you have in your array, then that aspect of utilization goes up.
You can still have increased utilization just by using what you have. Don't overprovision and more importantly recoup/recycle/redeploy what is nolonger needed.
Why does utilization typically suck?
The DBA tells the host admin, "I need 100GB for tablespace." When he needs 50GB but doesn't want to ask the vmware admin in 6months for more space.
The vmware admin tells the storage storage guy, "I need 200GB for ESX server XYZ" because he doesn't want to have to ask the storage guy in 6months for more storage.
The storage guy then allocates 400GB to ESX server, but he doesn't want to be bothered in 6 months for another request.
So what started out as a 50GB request, becomes 400GB because nobody wants to be bothered in 6months to deal with a request for more storage. Combine this with the request that this storage be mirrored then replicated and now your 50 GB has spawned 800GB of additional capacity bringing the original 50GB request up to a whopping 1200GB.
Tying $/GB by integrating in snapshots, synchronous replication etc etc.. throws your whole model out of whack. Remember, 5years ago you only wanted snapshots, sync replication, point in time copies, continuous backups for a tiny percentage of your array.
So stop complaining up there in your ivory tower, roll up your sleeves and try fixing the problem.
Reply to this comment