Thin provisioning reduces storage consumption by allowing planning 
for consumption at a higher level other than an application. Without thin provisioning, we are forced to plan disk consumption and anticipated growth at an application level.
For example, your inventory control system is currently using 100GB. You have seen this application grow at 30 percent per year. So, now when it is time to move this application to a new storage platform you do a little math. (In some circles we call this math planning.) The math goes like this:
Current space consumed + (growth rate* time to review again). In our case, we have 100GB plus 30 gigs per year and we don’t want to fuse with this for three years. Please note growth rate is compounded.
|
Timeframe |
Spaced needed |
Over allocated |
|
Day one |
100 GB |
120 GB |
|
End of year one |
130 GB |
90 GB |
|
End of year two |
169 GB |
51 GB |
|
End of year three |
220 GB |
0 GB |
In setting up the new array, you give this application 220GB—and therefore you are wasting 90GB at the end of the first year. I am sure some management person would say, “Hey--just review this growth more often and therefore eliminate the over allocation.” Good thought, but bad things happen if we do not have enough space allocated to the application...like crashes.
The disk manufacturers came out with a technique called “thin provisioning” to help us with this problem. In our example, it works by telling the application it has access to 220GB, but it really consumes only whatever amount is used.
So how should we best use this technique to our benefit? First make sure you understand the rules or restrictions the disk manufacturer has on this feature. Next do not think this feature relieves you from the responsibility of keeping track of available space. In reality, you need to do the same type of planning for space, but now it is at a higher level --a level where there are many applications consuming/competing for the same free space.
Managing an available pool of unused disk is at a ratio of many to one. Therefore, the ramification of running out of space in the thin world is that you will crash as many applications that are associated with that pool of storage...ouch!
Why not set what your application sees to the limit of what the operating system can address? Because this would actually allow the application to grow to its next constraint. Be careful if you deploy this type of strategy. Some operating systems will write out super blocks and thus consume space.
Now that we understand that thin provisioning can increase our efficiency associated with used vs. allocated space, what happens when the file system starts to add “thin thinking” to its bag of tricks? I’ll be reviewing this over the next several weeks.
Visit Adexis at www.adexisstorage.com
Recent Comments