The Myth of Thin Provisioning
The modern SAN (Storage Area Network) manufacturer is contending in a brutally competitive world. Every manufacturer has a list of bells and whistles. This checkbox of feature haves and feature have-nots is the starting point for any comparison shoppers’ entry into the research, recommendation and purchase process. This, of course, is nothing new and is accompanied by the usual tactics which (unfortunately) include FUDD (Fear, Uncertainty, Doubt, and Disinformation) as well as features that are otherwise useless and looking for a market.
Nearly all manufacturers to-date have adopted the new “standard” feature set for the modern SAN which include:
- Snapshot technology (and quiescence technology by extension)
- Mirroring and Replication technology
- Thin provisioning
With any feature war the business fiefdom’s develop quickly. For snapshots, the copy-on-write crowd will lob grenades at the redirect-on-write crowd and vice versa. For now however, I would like to concentrate on The Myth of Thin Provisioning.
Thin provisioning is the over-allocation of storage to the host. As an example, let’s say that you provision 1TB of thin-provisioned storage from your new, modern SAN and write only 200GB of data to it. With standard, fat or true provisioning 1TB of physical disk would be utilized. With thin provisioning only the 200GB of disk space would be utilized initially (and typically a small amount of overhead). However, with operating systems such as MS Windows this benefit is quickly negated due to the nature of the NTFS file system.
This over-simplified diagram depicts the net used disk space on a thin provisioned LUN after the following operations:
- 200GB file written
- 100GB file written
- Original 200GB file deleted
- Additional 100GB file written
Logically, you might expect that last operation “4. Additional 100GB file written” to write to the first section of the disk which is now free space due to the third operation “3. Original 200GB file deleted”. However, this is not the tendency for an NTFS file system. Instead, it starts where it left off.
In the case described above, if thin provisioning was a perfect feature only 300GB of disk space would have been used. Instead, 400GB of disk space is used. For NTFS at least, it all comes down to the amount of “flux” or data write, delete, re-write that occurs as well as the size of these data sets written. For example, if you are storing your Ghost or Acronis images on a thin provisioned volume The Myth would be revealed quickly. Like any feature of any product these features cannot be utilized effectively without first understanding how and why the work with other variables in your environment: NTFS versus ext3 for example!
The Danger Zone
The prevalence of MS Windows operating systems globally, and the NTFS file system by extension, ensure that without a solution, most IT shops using thin provisioning will eventually (and quickly in some cases) eliminate the value and enter a danger zone. There are three things to consider here:
- A: How much data “flux” has occurred (your hard usage)?
- B: How much disk did you buy (your hard ceiling)?
- C: How much disk did you provide to your systems through thin provisioning (your soft ceiling)?
The question: If A hits B and your systems request additional net-new disk space to write to, what happens? The answer: Your IT staff has a very bad day.
Avoiding the Danger Zone
First, watch Top Gun on mute, sorry…had to add the reference. Second, or rather “really-first”, deploy your SAN feature set intelligently. Use thin provisioning where it makes sense:
- The boot drive of the system (assuming boot from SAN and your page file is elsewhere)
- Generally static data sets – archive targets
Or, at the least, don’t use it where it does not make sense:
- Generally dynamic data sets – temporary storage areas, development build locations, etc.
Third, deploy an enterprise wide intelligent defragmentation tool that consolidates data to the first sectors of the disk. True, running defragmentation once takes a long time however nightly, it should be acceptably fast (something like Diskeeper).
Conclusion
Deploy your SAN feature set in the most appropriate way. When sizing for a future purchase don’t count on marketing numbers for thin-provisioned savings. Instead, think about your actual environment and make an educated guess where thin-provisioning will be an asset.
To discuss, tell me I am completely insane, or otherwise give me a rough time feel free to call/email/skype:
Rob Kinney
(440) 498-2300 x232
Email: rkinney@chicorporation.com
Skype: rkinney
Related posts:
(No Ratings Yet)
Loading ...
