Share This:

In my last three posts (Clouds in the Glass House, Clear to Partly Cloudy,  and Convergence) I have spent a fair amount of time talking about the current  latest greatest computing paradigm: clouds. My position has been somewhat counter to the current fashion trends. If you have read the other posts, hopefully I have been clear on my central point that "Cloud Computing" is not a thing, but a concept or a paradigm. It is a way of thinking of a certain set of technologies being used, and not even in one particular way.


The more I think about "Cloud Computing" the more I think the term fits the concept: it is every bit as fuzzy, ill defined, and nebulous as a real cloud. Ironically, unlike other trends of the past, and unlike a cloud, "Cloud Computing" is *not* vaporware either. It is real, and there are actual products behind it. That is because in many cases it is an old product or concept with the serial numbers filed off, and in others it is just a collection of products meant to be used in a "Cloudy" way. I am thinking here a great example is provisioning / rapid provisioning. It was there before the cloud, but it is key to a clouds basic concepts, at least as most people think about and discuss "Cloud Computing". Same thing with Software As A Service (SAAS) although it would be more accurate to think of "Cloud Computing" as delivering the platform for SAAS.


Thin Provisioning


I have to say that I dislike the term "Thin Provisioning" as is has been applied storage, usually virtual storage. "Hey: has your provisioning lost weight?"


If :


  • "Bringing provisions" in the traditional sense was something like "I packed a lunch"  and ...
  • In the server sense is that "I bought and set up a server so you can use it"  and ...
  • "Rapid Provisioning" means "We used automation to rapidly configure or reconfigure the server to meet your current needs" ....



... Then I somehow have trouble with how that leaped technical meanings in block storage. Seems like "Thin Provisioning" would be a better term for "You asked for something, so I gave you less".


Sure, in storage thin provisioning does kind of mean that: "You asked for 100GB, and I gave you 5GB with the ability to invisibly grow to 100GB should it turn out you really need it. But the OS thinks it has a 100GB LUN there, and will happily use it all, so  the reality to the OS is that it has 100GB LUN. End of Story.


The term I like better is "Storage Overcommitment" (and yes, I know that is usually used to discuss RAM in a virtual system) because that is the real win of Virtual Storage. In the real world, you can set upp 100 LUNS, each with only 5GB in use at the set up time. Because the LUN is virtualized, and only allocates blocks as they are used, the actual on-disk storage of such a setup would be 500GB plus a litte overhead, when the hosts using the storage total up to 10,000 GB. You can they provision this storage on a device with *more* than the 500GB, but way less than he 10,000 GB and *overcommit* the storage.


You monitor and watch it of course. Some will actually end up using more than their starting allocation, but in the real world there are many computers that are only using a tiny fraction of their built in storage capacity: My mom has 120GB disk in her iMac, and even with all her music and pictures she is not using more than 25% of that.


This does not even count the possibility in "Storage Overcommitment" (SAN / WAN Storage overcommitment? DASD overcommitment? Block storage overcommitment?) of data-deduplication If all 100 of those hosts were the same OS: Say Ubuntu 9.04, and your storage could just keep pointers to the same data item.  All of the common parts of the OS and applications therein would be stored once, with pointers, rather than a separate copy for each. Now you have the *first* hosts 5GB storage, but every hosts after that storage only having its unique elements stored: maybe 2 or 3 GB each. Pictures and music and /var and /etc mostly get separate storage, but the kernel and the .deb archives and whatnot are only stored once. If half the hosts are running Oracle, then the Oracle Binaries are also only stored once, but the database is stored uniquely.. unless it is the same data base.... On and on....


It is this set of features that to me make the term "Thin Provisioning" a very weak term, and not at all descriptive. Nothing can be done about it though: It is the common usage. I supposed some would take my term and think it means that the storage is clingy and needy and jealous. "Have you been seeing other SAN's?!?! I thought we had a commitment!!!!"


Whats in a Word?


I hit a terminology road bump like this recently. I was designing a new R&D data center, and when talking to the contractors about the total heat load of the room, I keep referring to the maximum rating of the power supplies for the computers. They were very confused until we hit upon the term "Nameplate". Thereafter I used that term, because there was no understanding of the idea that "maximum rating", "maximum output" or UL rating or any other terms like that was the same thing. I thought that was unique until I was talking to a different vendor about wattage and they also were confused breifly till I hastily added the term "Nameplate" to the conversation. The funny thing was that it was not really a conceptual problem with the idea that a computer does not *use* the max rating of its power supply very often: We were in fact talking about what the local code was when it came to UPS, Air Conditioning, Amperages required to feed racks, and so forth, and what the ratio of the max rating to the static rating is. (I did not say static rating: That would have been confusion too). All were clear on the concept, but had hung their understanding of the system on a term that had, when you think about it, no meaningful relationship to what we were discussing. "Nameplate". Nothing in that term screams wattage at me. In fact, when I think nameplate, I think the name on the front of the asset, and it may not even be a computer. Dodge Ram is a nameplate. Honda Fit is a nameplate. Has nothing to do with computers.


I guess this why ITIL is so important. People have to speak the same language and use the same terms even if the terms are not conceptually accurate. I was listening in to an architect talk about designing a building once, and they kept talking about "Programming" a room. Really? The room runs programs? How cool is that? I'll bet the rooms OS is Linux....


Next time: Virtualization update


The postings in this blog are my own and don't necessarily represent BMC's opinion or position.